Answered the way we would answer them on a call. If yours isn’t here, ask it directly — we would rather give you a short honest answer than have you guess.
There is no useful list price, because the honest answer depends entirely on scope. What we can commit to is how the number is arrived at: we run a paid discovery week, write down exactly what is being built and what is excluded, and quote a fixed price against that document before any code is written. You approve the scope and the price together. Anything added later is priced as a change rather than absorbed into a deadline that quietly slips.
Arithmetic, not discounting. There are three of us and all three write code. There is no office, no sales team, no account manager, no project manager relaying requirements, and nobody on the bench between projects whose salary has to be covered by the projects that are running. Those costs are real for an agency and they land on the invoice. We do not have them, so you are paying for build time.
Discovery and a written scope take about a week. After that, an integration between two systems is typically two to four weeks, a document or email processing pipeline three to six, and an internal tool that replaces a spreadsheet four to eight. Anything larger, we break into pieces of that size and ship them one at a time rather than disappearing for six months.
Yes, completely and from day one. The source lives in your repositories, not ours. Cloud accounts, domains and API keys are created in your name. The database and everything in it is yours. Walking away should cost you nothing beyond the work already done, and that is deliberate — a build that leaves you dependent on the people who built it is not finished.
Yes. The work is remote by default and always has been. In practice that means written scopes, recorded walkthroughs and something running you can try at the end of each cycle, rather than status meetings that need everyone awake at once. We overlap live for the conversations that genuinely need to be live.
Fixed price against a written scope, agreed before the build starts. We would rather take the estimation risk than hand you an open meter, and it keeps the incentive pointed at finishing rather than at billing more hours. Ongoing support after launch can be arranged on a retainer if you want it.
It goes live on infrastructure in your name, with the keys handed over, written documentation and a recorded walkthrough as standard. From there, support is optional. Some clients take a monthly arrangement for changes and monitoring; others take the handover and run it in-house. Neither one is a condition of the other.
Sometimes, and we will look before we answer. If the existing system is sound and just unfinished, picking it up is usually cheaper than starting again. If it is not, we will say so plainly and explain what specifically makes it cheaper to replace than to repair, rather than reaching for a rewrite by reflex.
TypeScript with React and Next.js on the web, Node.js or Python on the backend, React Native for mobile unless the app needs something only native gives it, and PostgreSQL unless there is a specific reason for something else. Hosting goes in your own cloud account. If your team already runs a different stack well, we build in that instead — the technology should match whoever maintains it afterwards.
Yes, and it happens regularly. If an existing product does the job for a monthly fee, buying it beats building it, and we will name the product and explain how to configure it. A short honest answer is worth more to us than a long engagement that should not have started.
Yes. Send yours across before the first detailed conversation if the subject matter needs it, and we will sign it. We do not publish client names or project details without written permission either way.
Email a description of the problem in plain language — what is slow, manual or breaking, what you have already tried, and rough timing. The first conversation costs nothing and usually clarifies the problem whether or not we end up working together.
Describe the problem in a paragraph. We’ll tell you whether it’s a build, an automation, or something you should just buy.