Question 1

Do you sign an NDA?

Accepted Answer

Yes, and we sign it before we see your code, your designs, or anything else sensitive. We'll sign yours, or send over our standard mutual NDA if you don't have one. This is routine for us — after 16 years of offshore work, most of what we've built we can't even name publicly.

Question 2

Who owns the code and IP?

Accepted Answer

You do. Our contracts assign full IP ownership to you once the work is paid for — source code, designs, documentation, all of it. We don't reuse your code on other projects, and we don't hold your repo hostage. It's your product; we're just the ones building it.

Question 3

What about open-source libraries and pre-existing code?

Accepted Answer

Almost every modern app uses open-source libraries, and we stick to permissive licenses (MIT, Apache, BSD) unless you approve otherwise. If we bring in anything with a copyleft license or a paid component, we flag it first. We keep a dependency list so you always know exactly what's in your codebase.

Question 4

Is there a written contract and scope of work?

Accepted Answer

Always. Every project starts with a signed agreement plus a scope document that spells out deliverables, timelines, payment terms, and what happens if either side wants out. Verbal agreements cause fights; paper prevents them. We'd rather spend a week getting the SOW right than argue about it in month three.

Question 5

What happens to the code if we stop working together?

Accepted Answer

You keep everything you have paid for — repos, credentials, docs, deployment details. You have admin access to your own repositories from day one, so there is never a moment where we are holding your code hostage. We do a proper handover, not a dump-and-run. And if you want an extra layer of protection, yes, we set up code escrow on request.

Question 6

What does your process actually look like?

Accepted Answer

Discovery first — we ask a lot of questions, sometimes annoyingly many, until we understand what you're building and why. Then we break the work into two-week sprints with a demo at the end of each one. You see working software every fortnight, not a big reveal at the end. That rhythm catches misunderstandings early, when they're cheap to fix.

Question 7

What tools do you use to communicate?

Accepted Answer

Whatever your team already uses. Slack or Teams for daily chat, Jira or Trello or Linear for tickets, GitHub or GitLab for code, and a weekly video call at minimum. If you don't have a preference, we'll set up Slack plus Jira and invite you to both. Everything is written down — decisions made in calls get summarized in writing the same day.

Question 8

Can I talk to the developers directly?

Accepted Answer

Yes, and we'd prefer you did. You get direct access to the people writing your code — same Slack channel, same standups. A project manager coordinates and keeps things moving, but they're not a wall between you and the team. Middlemen who paraphrase requirements are where offshore projects go wrong.

Question 9

How do you handle scope changes?

Accepted Answer

We expect them — no real project ends exactly where it started. Small changes get absorbed into the sprint. Bigger ones get a short written estimate of the time and cost impact, and nothing proceeds until you approve it. What we won't do is quietly say yes to everything and hand you a surprise invoice later.

Question 10

We've been burned by an offshore team before. Why would this be different?

Accepted Answer

Fair question, and we hear it a lot. The usual failure pattern is a sales guy who disappears after signing, developers you never meet, and silence between milestones. We run it the other way: direct developer access, working demos every two weeks, and honest bad news early instead of good news that turns out to be false. We've been doing this 16 years and 250+ projects — most of our work comes from referrals, which only happens if the last client was happy.

Question 11

What are your overlap hours with the US and Australia?

Accepted Answer

We are in Jodhpur, India (IST). Australia is the easy one — our afternoon lines up with most of your working day. For the US, our team shifts hours to guarantee 3 to 5 hours of shared time with your morning (East coast) or afternoon (West coast). Standups and calls go inside that window, so you are not waiting a full day for a reply.

Question 12

How do you price — hourly, fixed, or dedicated team?

Accepted Answer

All three, depending on the project. Fixed price works when the scope is well defined — you know the number before we start. Hourly (time and materials) suits evolving projects where scope will shift. A dedicated team on a monthly rate is best for ongoing product work. We'll tell you honestly which model fits your situation, even when it's not the one that pays us more.

Question 13

Are there hidden costs I should worry about?

Accepted Answer

No, and we'll list the costs that aren't ours so you're not surprised: hosting (AWS, etc.), app store developer accounts, paid third-party APIs, SSL and domains, and any premium licenses your product needs. Those are billed at cost or paid by you directly — we don't mark them up. Our own quote covers our work, and changes to it require your written approval first.

Question 14

Why are you so much cheaper than US or Australian agencies? What's the catch?

Accepted Answer

There's no catch, just geography. Cost of living in Jodhpur is a fraction of San Francisco or Sydney, so a senior developer here earns a good local salary at a rate that looks impossibly low from abroad. Same tools, same GitHub, same standards. Where offshore actually goes wrong is communication and accountability — which is why our process leans so hard on demos, written decisions, and direct access to developers.

Question 15

What does the ~$20/hour rate actually include?

Accepted Answer

Our $20/hour is a senior developer, and it already covers project management, code reviews and standups — not a stripped rate where every email costs extra. Other roles are priced separately and lower: junior developers, QA engineers and designers run about $15/hour. So a full team blends down to a number that is hard to match onshore. The rate works because we are in Jodhpur, not because we cut corners.

Question 16

How is payment structured?

Accepted Answer

Both ways, depending on how you engage us. Fixed-price projects are split across milestones — a deposit to start, then payments tied to delivered and approved work. Hourly and dedicated-team work is invoiced monthly against tracked hours you can review. You are never handing over a big sum for work you have not seen.

Question 17

Do you require an upfront deposit?

Accepted Answer

For fixed-price work, yes — 10 to 20% upfront to kick things off. It is a milestone payment, not a blank check; the rest is tied to delivery. For dedicated teams and hourly work there is no big deposit. The first monthly invoice covers the opening period and billing runs from there.

Question 18

Who will actually be on my team — and are they dedicated or shared?

Accepted Answer

You'll know your team by name before the project starts, and on dedicated engagements they work only on your project. We don't do bait-and-switch, where the seniors show up for the sales call and juniors do the work. For smaller fixed-price projects, some specialists (a designer, a DevOps engineer) may be shared across projects, and we'll tell you which ones.

Question 19

How do you ensure code quality?

Accepted Answer

Code review on every pull request — nothing merges unreviewed. QA testing before anything reaches you, automated tests where the project warrants them, and consistent coding standards across the team. We're ISO 9001:2015 certified, which forces documented process on us, but honestly the reviews and the demos matter more day to day. You can also have your own tech person audit the repo any time; it's your repo.

Question 20

How do you handle data security, and where does our data live?

Accepted Answer

Your production data lives wherever you choose to host it — usually your own AWS, Azure, or GCP account, in your region, under your control. We access it only as needed and through accounts you can revoke. Internally we use access controls, VPN, and signed confidentiality agreements with every employee. For development we work with test or anonymized data wherever possible rather than production copies.

Question 21

Do you write documentation?

Accepted Answer

Yes — setup and deployment docs, API documentation, and inline code comments are part of the work, not an add-on. The blunt test we use: could a competent outside developer pick up the project from the docs alone? If the answer is no, we're not done. You should never be locked in because only we understand the code.

Question 22

Can we interview the developers before committing?

Accepted Answer

For dedicated-team engagements, yes — you can interview the proposed developers, review their experience, and reject anyone who doesn't feel right. It's your team; you should be comfortable with who's on it. For small fixed-price projects we assign the team ourselves, but you'll still meet everyone in the kickoff.

Question 23

What if a developer leaves mid-project?

Accepted Answer

We replace them free, and we build in a handover overlap before the departing developer's last day whenever the timing allows. Nothing lives in one person's head — code gets reviewed and documented as we go, so no single developer is a point of failure. Our attrition is low and a lot of our engineers have been here for years. But people do move on, and the process is built to absorb it without stalling your project.

Question 24

Do you provide maintenance and support after launch?

Accepted Answer

Yes. Most clients move to a monthly support arrangement after launch — a block of hours for fixes, updates, and small improvements, sized to what the product actually needs. Others come back project-by-project as new features come up. Either works; we've supported some products for the better part of a decade.

Question 25

Can you take over an existing or legacy codebase?

Accepted Answer

Yes — a good share of our work is rescuing or continuing projects started elsewhere. We start with a paid code audit: a few days reviewing the codebase, then a written report on its actual condition and what it'll take to move forward. Sometimes the honest answer is that a rewrite is cheaper than a rescue, and we'll say so. What we won't do is quote blind on code we haven't read.

Question 26

How do you handle bugs found after release?

Accepted Answer

Report it and we triage the same or next business day. Critical bugs — anything breaking production — jump the queue and get worked immediately. Everything gets logged in the tracker so nothing disappears into a chat thread. During warranty, delivery bugs cost you nothing; after that, they come out of your support hours.

Question 27

Do you help with app store submission and updates?

Accepted Answer

Yes, end to end — App Store and Google Play submissions, store listings, screenshots, handling Apple's review feedback (and their occasional rejections), and pushing version updates after launch. The developer accounts stay in your name so you own the store presence. We've shipped enough apps that the review process holds no surprises for us.

Question 28

What is covered under warranty versus paid support?

Accepted Answer

Bugs in what we delivered — anything that does not match the agreed spec — get fixed free for 90 days after launch. New features, changed requirements, third-party API breakage, or problems from someone else editing the code fall under paid support. We tell you which bucket something lands in before we touch it, so there are no surprise invoices.

Questions Clients Ask Before Hiring Us

Contracts, IP & Confidentiality

How We Work Together

Pricing & Payment

Team, Quality & Security

After Launch

COMPANY

Expertise