The questions people actually ask

Because a number quoted against a requirements document written before anyone has examined the domain is a guess with a decimal point on it. Both sides discover that around month four, when the number stops being true and the relationship becomes a negotiation. We would rather charge a modest fixed fee for two to three weeks of discovery, produce a specification grounded in how your business actually works, and quote against that. If our number is then wrong for you, you still own the specification and can take it anywhere.

A fixed fee agreed before it starts, scaled to the size of the domain — for most engagements it is a low five-figure sum in rupees and takes two to three weeks. You get a written model of your domain: the entities, the states they move between, the rules that govern the transitions, and the exceptions we found that nobody had written down. Plus a build order and a real estimate. All of it is yours, in writing, whether or not you continue with us.

Frequently the difference is what is included rather than the rate. Low quotes for application work commonly exclude the backend, the admin interface, store submission, data migration, testing and any offline behaviour — which is to say they exclude the parts that take the time, and those parts reappear as change requests. Ask any firm you are comparing for a line-item breakdown against the same list. Sometimes the cheaper quote genuinely is better value, and if we think so we will say so.

Yes, for work whose shape is genuinely known — usually meaning after a discovery. What we avoid is a fixed price on a poorly understood problem, because that arrangement forces us to price in a large risk buffer and then to defend scope aggressively, and both parties end up managing the contract instead of the product. For work that is still being shaped, time and materials with an agreed monthly ceiling serves you better.

There is no fixed floor, but below a certain size we are the wrong choice and would say so on the first call. If what you need is a brochure site, a well-configured platform theme will serve you better and cost a fraction. Where we are worth the money is when there is a real domain model to get right — a process, a set of rules, an integration, something that has to be correct rather than merely present.

A written weekly summary — what moved, what did not, what is blocked and what we need from you — and a fortnightly demo against real data rather than against a prototype. You have access to the repository, the issue tracker and the staging environment from week one, so you can see the state of things without asking. Written-first is deliberate: across four time zones a decision record is worth more than any number of calls, and it is what makes handover possible later.

One person with the authority to make decisions, available for roughly two hours a week. That is genuinely the most important input, and projects stall on its absence more often than on anything technical. We also need access to the people who do the work — not only the people commissioning the software — because the exceptions that decide the architecture live with them.

They are expected, and building in slices exists to absorb them. Because each slice is a working piece of the system rather than a layer of it, changing direction costs the current slice rather than the whole plan. What we surface explicitly is any change that contradicts the domain model, because that is the expensive kind — you see what it costs before you decide, rather than us absorbing it quietly and running late.

Regularly, and it works best when the boundary is clear. Either we own a defined area end to end, or we join your process entirely — your repository, your review standards, your standup. What does not work is an ambiguous split where two teams both partly own the same code, because integration becomes everyone’s second priority and nobody is accountable for the seams.

Monday to Saturday, 10:00 to 19:00 IST. That overlaps comfortably with UK mornings and Australian afternoons; US calls are scheduled early or late by arrangement. In practice the time zone matters much less than the working style — teams that write things down get far more out of a distributed arrangement than teams that rely on someone being tappable on the shoulder, which is why we push for written updates and decision records.

You do, from the first commit. Work happens in your repository under your organisation account, not in ours. There is no escrow arrangement, no licence-back clause and no per-seat fee on something you paid to have built. If you stop working with us tomorrow, everything keeps running and any competent team can pick it up. We think a firm that needs to hold your code to keep you has already told you something about the work.

You leave. One month’s notice, we finish or cleanly stop the current slice, and we spend the remaining time on handover rather than on new work. Because each slice is a working piece of the system, you stop with something that runs rather than with a half-built layer. We would rather end an engagement well and be recommended than hold on to one that is not working.

Yes, routinely, and usually before the first substantive conversation if you would prefer. We will also sign yours rather than insisting on ours. The only clauses we push back on are ones that would prevent us working in an entire industry for several years, which is a different thing from protecting your confidential information.

The honest answer is that the structure is designed to make "wrong" visible early rather than to promise it will not happen. Two-week slices demoed against real data mean a misunderstanding surfaces in weeks rather than in months, and a paid discovery means the biggest unknowns are resolved before the largest spend. If we are the cause — a bad estimate, a bad technical decision — we fix it at our cost and we say so plainly rather than repackaging it as a change request.

This is a reasonable question to ask any firm and the answer should be specific rather than reassuring. Ask us directly during commercial discussions and we will give you the current position in writing, along with our standard terms, before anything is signed. We would rather answer it precisely at that point than post a general claim here that might drift out of date.

TypeScript, React and Next.js on the front end; Node.js on the back end; PostgreSQL as the default database; React Native for mobile; AWS for infrastructure. We also work in .NET, Laravel and Flutter, mostly where an existing estate or team makes that the right answer. The selection principle is deliberately dull: the largest hiring pool and the longest support window, so you can hire someone to maintain this without us.

Yes, and it is a normal way for us to start. The first two to three weeks are archaeology rather than development — reading the code, mapping what actually runs against what everyone believes runs, checking dependency and licence health, and testing whether the backups actually restore. You get a written assessment with risks ranked before we propose any work. Sometimes that assessment says the system is fine and needs three specific fixes, and we will tell you that rather than sell you a rebuild.

We use AI tooling the way the industry now does — for scaffolding, for tests, for the tedious parts. What does not change is that a person is accountable for every line that ships, every change is reviewed by a human who understands the domain, and nothing reaches production because a model was confident about it. Where we are more cautious than average is in putting language models inside your product: if a rule can express something, a rule should express it.

WCAG 2.2 AA is our working target, and most of it is decided in design rather than in code — contrast chosen when colours are chosen, focus order specified alongside layout, keyboard behaviour designed alongside pointer behaviour. Automated tooling catches roughly a third of real problems; the rest needs someone to complete the task by keyboard and listen to what a screen reader announces. If you have a formal compliance requirement, tell us at the start, because it changes some design decisions.

Data minimisation first — the cheapest way to protect a field is not to collect it. Then encryption in transit and at rest, role-based access at the schema level rather than in the interface, audit logging on anything sensitive, and a defined retention policy agreed before the build rather than after. Where India’s DPDP Act, GDPR or a sector-specific obligation applies, we map the specific requirements during discovery instead of assuming a generic posture covers them.