A few things you might be wondering.

Send us a description of what you are trying to build or fix — a paragraph is enough, a specification is not required. We reply within one business day and propose a call. If what you need is clear enough to scope, the call is followed by a written scope and estimate. Nothing is billable until you have both of those in front of you and have agreed to them.

An engineer, not a salesperson. We will ask what the system has to do, who uses it, what already exists, what your deadline is driven by, and what happens to your business if it slips. Expect us to push on the parts of the brief that are vague, because those are the parts that turn into change requests later. If the call ends with us saying we are not the right fit, that is a legitimate outcome and it costs you nothing.

The people building it. We are a small team of engineers and there is no account manager sitting between you and the work. The same people who design and build your system are the ones who deploy it, operate it and answer when something breaks. That is the main reason we stay small.

Yes. We work in your repositories, your ticketing system and your review process, under whatever conventions your team already uses. What we need in return is a named technical counterpart on your side who can make decisions — without that, work queues up waiting for answers and both of us end up frustrated.

Yes. It starts with a technical audit: we read the code, the infrastructure and the deployment path, and document what is actually there, including the parts nobody has looked at in a while. You get a risk report ranked by severity and effort before either of us commits to anything further. If the audit says the honest answer is a rebuild rather than a rescue, we will tell you that, and we will tell you what it would cost either way.

When it is the right answer. If an off-the-shelf tool solves your problem for a fraction of what custom software would cost, we will say so, even though it means we do not get the work. It is a bad trade for us in the short term and a good one in the long term — and it is easier than explaining, a year in, why you are paying to maintain something you could have subscribed to.

It depends on what it has to do, so we publish ranges rather than one figure. A few pages that get you found is ₹15,000 to ₹40,000. A website designed for you rather than adapted from a template is ₹40,000 to ₹1,25,000. Something people can actually use — bookings, payments, logins — is ₹1,25,000 to ₹4,00,000. A full platform with several kinds of user and approval steps starts around ₹4,00,000. Looking after it afterwards starts at ₹8,000 a month. The How we work page has the full table and the things that move the number: buildfoundry.in/how-we-work#pricing

Below ₹15,000 we will tell you to use Wix or Shopify and keep the money. We would rather say that than take a job we cannot do properly at that price. The same applies at the other end — if what you need is a team of fifteen, we will say so.

We break the work into pieces small enough to reason about, estimate each one, and write down the assumptions we made to get there. You receive those assumptions with the number. If we have assumed you already have a payment provider, or that there is no legacy data to migrate, or that a third-party API behaves as documented, it will say so — so you can challenge the assumption rather than the total. Where an assumption turns out to be wrong, that is a conversation about that one line rather than a renegotiation of the whole number.

Scope, integrations and uncertainty, roughly in that order. The number of distinct things the system does; how many external systems it has to talk to and how well those are documented; whether data has to be migrated out of something older; how many user roles and permission rules exist; and how much of the requirement is still being discovered. Compliance requirements, high availability and existing code you need us to keep working within all add to it. Design polish and long-term support are separable — we will price them separately so you can see what you are choosing.

We quote the change separately and you decide. It is never absorbed silently and it never appears as a surprise on an invoice at the end. Scope changing is normal — most useful projects learn something in month two — so the process for handling it is agreed at the start rather than negotiated under pressure in the middle. If the requirements are still genuinely moving, a monthly retainer will cost you less than a fixed-scope project with a queue of change requests attached to it.

That is ours to absorb. Fixed price means fixed: if we misjudged something we should have foreseen, we finish it at the agreed price. The exception is a change to what you asked for, which is a different thing and is quoted as one. This is why we spend real time on scoping before quoting — the estimate is a commitment, so we would rather it be slow and right.

You do, entirely, from the first day rather than at the end. Code lives in your repositories, infrastructure runs in your cloud accounts, domains and third-party services are registered in your name, and documentation is written where your team can find it. There is no handover event because there is nothing to hand over — it was yours while we were working on it. We keep no rights to anything we build for you.

Yes, and mutual NDA plus IP assignment are signed before any engagement begins — including before we look at an existing codebase during an audit. If you are an agency engaging us to work under your brand, we work under your name, we do not contact your client directly, and we do not list the work anywhere.

Fixed-scope work starts on a 30% advance, with the balance split across the delivery milestones in the scope document and invoiced as each one is signed off. Retainers and support are invoiced monthly in advance. Invoices are due within fourteen days. We do not charge interest on a late payment, but work pauses on an unpaid invoice rather than quietly continuing and growing the balance. Nothing is billable before you have a written scope and an estimate in front of you and have agreed to both.

No, and no. Build Foundry is a registered micro enterprise under the Udyam MSME scheme, but it is not registered for GST — so invoices carry the Udyam number rather than a GSTIN and no GST is added. That means there is no input tax credit to claim on what you pay us. If your finance team needs one, say so in your first message rather than discovering it at the invoice. Indian clients are invoiced in rupees by bank transfer or UPI; international clients in US dollars or pounds.

Typically TypeScript across the stack: React and Next.js on the front end, Node.js services behind it, PostgreSQL or MongoDB depending on the shape of the data, containers and CI/CD for delivery. We also work in Python and Java where a project already lives there. The stack follows the problem and your team’s ability to maintain it — if you have in-house engineers who will own this after us, their familiarity outweighs our preference.

Yours. We will not host your production system inside our own account, because that quietly turns an engineering relationship into a dependency and makes leaving harder than it should be. Everything is applied to accounts you own and control the billing for, so you can revoke our access at any point and lose nothing. On larger systems that setup is defined in code so it can be rebuilt exactly; on a small one it is configured once and written down, because infrastructure-as-code on a five-page site costs more to maintain than it saves.

Yes. We use your version control, your issue tracker, your chat and your review process rather than asking you to adopt ours. If none of that exists yet, we will set it up in your accounts and document it, so it stays useful after we are gone.

How much automation depends on what breaking would cost you, and we will tell you where that line falls rather than quietly picking for you. What does not vary: the journeys that would hurt most if they failed — signing up, paying, anything that moves money or records — get automated coverage, and it runs before a release rather than after. Around that, API and permission testing where the rules are complicated, and a person for the things automation judges badly: whether a screen looks right, how one particular device behaves, what happens when somebody uses it in a way nobody expected. Anything found by hand goes into the automated set so it cannot come back quietly. Some testing is part of the work and not a line item you can decline.

Authentication, authorisation, rate limiting and audit logging are designed in at the start rather than retrofitted after a security review. Permissions are enforced on the server, never only in the interface. Secrets live in a secret manager rather than in a repository or a deployment script. Dependencies are kept current and security advisories are reviewed on a schedule, because upgrades left long enough stop being upgrades and become migrations.

Yes, and it is most of what support engagements actually consist of. A user who cannot log in, an import that stopped halfway, a report showing a number your team disputes, a webhook that did not fire — small things that block somebody right now and need someone with access who knows the system. Your team raises it in a shared channel, an engineer looks at it, and it is dealt with against an agreed response window. Hours are pooled monthly rather than billed per ticket, so nobody hesitates to ask.

Anyone. Operations, finance, customer support — it does not have to be routed through a technical person first, because in most of the companies we work with there is not one. Describe what happened and what you expected; we will ask if we need more.

Usually, and we think you should want us to. Launch is when a system starts producing information about itself, and the team that built it is the team best placed to act on that. If you would rather take it in-house, we hand over properly — documentation, runbooks, a walkthrough with your engineers, and time available for questions afterwards.

Defect triage and resolution against a response window written into the contract, security patching, dependency upgrades, infrastructure maintenance including certificates and backups, monitoring and alert tuning, and continued feature development. Performance work is included, but we measure the bottleneck before changing anything — optimising the wrong thing is just slower.

There is one number and no argument about whose responsibility it is, because the people who designed and built the system are the people operating it. Escalation paths and response windows are agreed in writing before they are ever needed, and every incident is followed by a written review of what happened and what changed as a result.

Thirty days, in either direction, at any time. There is no minimum term on a retainer and no penalty for ending one. We would rather you stayed because the work is good than because the contract made leaving expensive.

You already hold everything: the code, the infrastructure, the accounts, the documentation. We spend the notice period on a real handover — writing down what is not yet written down, walking your next team through the architecture and the parts that are unintuitive, and staying reachable for questions after the last invoice. Nothing about how we work is designed to make leaving difficult, and if you ever come back it is because you chose to.

Mumbai, India — Indian Standard Time, UTC+5:30. Where you are is not a constraint — what matters is how many hours of your working day fall inside ours, and almost every timezone shares a workable window with IST. Ask and we will tell you exactly what the overlap looks like for yours.

Our afternoon is the European and UK morning, so a shared window there is straightforward. For North America the overlap sits at the ends of our day: our evening is the US East Coast morning, and our morning is the previous evening on the West Coast. We agree a standing overlap window with each client and hold it, rather than expecting you to take calls at times that suit us.

It does if the work is structured so that we need an answer from you before we can continue. It does not if decisions are batched, questions are written down clearly and scope is agreed far enough ahead. We work asynchronously by default and use the overlap window for the conversations that genuinely need to be conversations — which, done properly, means you get a working day of progress reported each morning.

In your tools — your chat, your issue tracker, your board — rather than in a portal we own. Written updates on what moved, what is blocked and what we need from you, plus a scheduled call in the overlap window at whatever cadence suits you. If you are an agency, communication runs through your project manager and never past you to your client.