Answers
What to know before you hand anyone a budget for software: price, ownership, risk and the day-to-day, answered in writing.
| Questions | 66 |
|---|---|
| Not here? | Ask it directly |
How work is scoped, quoted and paid for.
What does this cost, and why isn't it on the site?
Every engagement is quoted in writing before it starts, so you know the number before any code. An MVP week is a fixed price. A Rescue assessment is a fixed price. Larger builds are quoted per phase against a written scope, and consultancy runs at an hourly or day rate agreed up front. There is no rate card because the number depends on the scope, and we would rather quote yours than publish an average.
Fixed price or hourly, and who carries the risk?
A build with a definable outcome is a fixed price against a written scope, which puts the estimating risk on us. Consultancy, covering architecture review, working alongside your engineers and advisory time, is billed hourly or by the day, because there is no fixed deliverable to price.
What if the work turns out bigger than the scope?
If we misjudged the estimate, we finish the agreed scope at the agreed price. If you add to the scope, we price the addition before starting it. Nothing arrives as a surprise on an invoice.
Do you take equity instead of fees?
Not as a rule. The default is cash for work; for the right project we will discuss a mix.
How do we start, and how fast do you reply?
Tell us what the product has to do. You get a reply within one business day, usually with questions, then a short call to agree what "done" means, then a written scope with a price and dates.
Is our project too small for you?
For a build, the smallest unit is an MVP week. Consultancy has no minimum: a few hours on an architecture decision is a normal engagement, and often the most useful one.
What you own, and what happens when the engagement ends.
Who owns the code?
You do, from the first commit. The repository and the intellectual property are yours, with no licence back to us and no rights retained.
Do you host anything on your side?
No. Cloud, domain and third-party services are provisioned in your accounts, under your billing, from day one. We work inside them.
Is there any lock-in?
None. No licence, no hosting, no required retainer and no proprietary framework only we can maintain. We are finished when you can run your product without us.
What do we actually get at the end?
A documented repository, the decisions written down with their reasoning, a walkthrough with whoever will maintain it, and a written note on what to build next and what we deliberately left out.
Do we have to keep paying you afterwards?
No. Support is available on a retainer, and it is optional by design: the code is conventional and documented so another engineer can take over without us.
What if we hire our own engineers later?
That is the intended ending. We help onboard them, and the code is written for someone who was not there when it was built.
What if we hate it at the end?
You see a working deploy at the end of every day, so the end is never the first time you see it. If it is going wrong, you know on day two and we change course then.
How the day-to-day runs.
Who will I actually be dealing with?
Roy van Kaathoven, who writes the specification, reviews the work and runs the handover. There is no account manager between you and the person doing the work.
Can you work with our team without taking over?
Yes. We can own one part of the product and stay out of the rest, or set up the platform and practices and hand them back. Either way, we leave nothing your team cannot remove.
Our codebase is a mess. Will you work in it?
Yes. We read it first and give you the cost of building on it against the cost of replacing the part in question, in writing, before you commit to either. That is what the Rescue assessment is for.
You are in Asia. Is that a problem?
No. We work from Taipei on hours that overlap Europe, so European mornings and Asian afternoons both work. Written updates cover the rest.
How much of our time do you need?
About two hours on day one to settle scope, then a daily review of what shipped. Decisions within a day keep the timeline; slower ones stretch it, and that is the one dependency we cannot absorb.
How much of this ends up in meetings?
Very little. Slack or email day to day, a short call when a decision needs one, and a working deploy to open at the end of each day. No status meetings.
Are you going to subcontract this?
No. When a project needs a designer or a specialist in a domain we do not cover, we bring one in and name them to you. We never subcontract the build and stay on as project management.
How AI is used in the work, and how your systems and data are handled.
What does "AI-first" actually mean here?
One engineer writes the specification, decides the architecture and reviews what comes back, while coding agents implement in parallel. It changes who does the typing, not who is accountable for the result.
Does someone read every line the AI writes?
No. Review goes where a mistake is expensive: the data model, the interfaces between parts, and anything touching money, authentication or data loss. Types, tests and a narrow set of conventions the agents are held to cover the rest, as on any team too large for one person to read everything.
Why would I pay for code a model wrote?
You are paying for a working result and for the person accountable for it. Agent output is a draft, reviewed by an engineer who has run production systems for fifteen years. Because generation is cheap, the code ships conventional, tested and documented as standard.
Will you use AI where it does not belong?
No. Where correctness matters more than flexibility, in billing, compliance or anything that reconciles, the model stays out of the path and a plain script does the job.
Does our code get sent to AI providers?
Yes, to the coding tools we build with. We name those providers in writing before work starts. If your agreements prohibit it, we work without them and quote accordingly.
Do you need our production credentials?
Only scoped credentials you issue and can revoke. Secrets live in a secrets manager, never in a repository or a chat message, and access ends with the engagement.
Do you sign NDAs?
Yes, before you send anything sensitive. Several case studies are covered by one, which is why some are described without naming the client.
What stops an agent reading data it shouldn't?
The tool layer. Agents read through views that exclude what they should not see, so the boundary is enforced in code rather than requested in a prompt. What is exposed is documented before anything is built.
Seven days from a scoped idea to a deployed product that real users can sign in to and use. One flow, built properly, in your own cloud account. Scope and price are fixed before any code is written; an overrun is our cost. Read the full page.
Is a week really enough?
For one flow, yes. We agree the single thing that proves the idea and build that properly, instead of half-building ten features. If your idea needs more than a week, you hear that before you pay anything.
What if you don't finish in a week?
An overrun is our cost. Scope and price are fixed on day one, and we finish the agreed scope at the agreed price.
Will the code be throwaway?
No. Coding agents produce conventional code and tests quickly, so there is no speed argument for cutting corners. Several products that started as one of these builds still run on that original codebase.
Who owns it?
You do, from day one. The repository, the cloud account and the domain are yours. No licence, no hosting lock-in, no retainer required afterwards.
What do you need from me?
About two hours on day one to settle scope, then a short daily review of what shipped. Miss the reviews and the week gets longer.
Your build never reached production. In days, at a fixed price, we read the code and the cloud accounts and give you a written verdict (finish, harden or rewrite), each with a cost and a date. Then we do the work, or you take the verdict to whoever you choose. Read the full page.
We don't know whether the code is any good. Can you tell us?
That is what the assessment is for, and why it is a separate, fixed-price step. We read the codebase, run it, and write down what is real. You keep that answer even if it ends the conversation.
It was built with AI. Is that a problem?
Not on its own. Plenty of agent-written code is fine. The problem is generated code nobody was in a position to review, so nothing caught the missing error handling, the auth check that was never wired up, or the migration that only ever ran on one laptop.
What if the answer is that we should start again?
Then the assessment recommends a rewrite and shows the reasoning, even though that costs us the larger finishing engagement. Using the existing product as the specification often makes a rewrite faster and cheaper than untangling what is there.
What if it is mostly fine?
That happens, and it is a good outcome. A build can be eighty percent there and stuck on a fortnight of unglamorous work (auth, migrations, error paths, a deploy pipeline) that the original team never reached.
The original developer or agency is gone. Does that stop you?
No. That is the normal case. We work from the code and the infrastructure, and where they disagree with the documentation, the code wins.
Can you work with whoever built it?
Yes, if they are still around. Half an hour with the person who wrote it is worth a day of reading.
Will you finish it, or only tell us what is wrong?
Either. The assessment is priced on its own, so you are not buying a build to find out whether you should. Most assessments turn into the work that follows.
How long does the assessment take?
Days, not weeks, for most codebases, at a fixed price agreed before it starts. It is small next to what finishing the build costs.
Who owns it at the end?
You do, throughout. Part of the first week is moving repositories, cloud accounts and vendor logins into your name, because in stalled builds they are often scattered across people who have left.
Triage, lookups, reporting, routing, first drafts. If it eats hours every week and is done the same way each time, we connect agents to your ticketing, CRM and databases so it runs without anyone doing it by hand, with plain scripts wherever a model is not reliable enough. Read the full page.
What can you actually automate?
Internal processes with a clear input and a clear output: support triage, lookups across systems, recurring reports, routing and assignment, first drafts. If a person does it the same way every time, it is a candidate.
Will it make things up?
Any language model can. We ground agents in your own data, use plain automation wherever correctness matters more than flexibility, and mark in writing which steps of a workflow are safe to hand over and which stay with a person.
Does our data end up with a model provider?
It stays in systems you control. Each task sees only the fields it needs, and we document exactly what is sent to which model provider before anything is built.
Have you actually shipped one of these?
Yes. Sakurai is an in-house Slack-native agent platform with more than fifteen focused agents covering support, code review, release notes, moderation and analytics, built on Nest.js with company services exposed over MCP.
What if we already use an off-the-shelf tool?
Keep it if it covers the work. Building pays off when the value is in the connections to your own systems, which a generic tool cannot reach.
You need a product built and have no engineering team to build it. We build all of it, from data model to deploy, as one accountable party, and hand over code your future hires can pick up without a rewrite. Read the full page.
What do you build with?
TypeScript end to end, React on the front, Node and edge runtimes on the back, Postgres underneath. Go or Rust where they earn their place. Native mobile when the product needs it.
We already have a designer. Does that clash?
No, we prefer it. We build to finished designs, or take a rough direction and shape the interface ourselves.
What if we hire an engineering team later?
That is the intended ending. The code is conventional and documented so a new team can take it over without a rewrite, and we help onboard them.
Do you do mobile?
Web first, native when the product requires it. We have shipped a native app alongside an app-store launch, including the payment and game-server integrations behind it.
Why quote per phase instead of one number?
So you know what each phase costs before it starts. Advice without delivery is billed hourly as consultancy instead.
Your engineers spend their week fighting the platform instead of shipping features. We take over the layer underneath (cloud, pipelines, reliability and the monthly bill) and leave it in a state your own team can run. Read the full page.
What does this actually run on?
Cloud-native and serverless. Production on Cloudflare's edge and on the usual providers, at sizes from a single service to a platform serving a global audience across multiple regions.
Do we have to put you on a retainer?
No. We can own it on a retainer, or take a defined project such as a migration, a reliability push or a cost cleanup, and hand it back in good shape.
Can you work with our engineers?
That is usually the best version. We set up the platform and the practices so your team can run it, and stay on as backup at whatever level you want.
Do you take on-call?
During an engagement, where it makes sense. The longer-term aim is monitoring and runbooks that make on-call manageable for your own team.
Is a cost cleanup worth paying for?
Usually; the first pass typically pays for itself. The savings come from oversized instances, forgotten environments, data leaving a region for no reason, and logs retained far longer than anyone needs.
Your developers optimise for shipping this week. We check whether this week's shortcut still holds next year. Architecture reviews, technical due diligence, and a second opinion on the decision you are about to commit to, billed by the hour or as a monthly retainer. Read the full page.
Our developer says they can handle the architecture. Isn't that enough?
Often it is. A good developer makes sound decisions inside the frame they have been given. The question is who sets that frame. If your developer is doing both jobs well, you do not need this.
Do we need a CTO?
Usually not a full-time one yet, and hiring early is expensive in salary and equity. What most teams need is someone senior on the compounding questions for a few hours a month. Outgrowing that is a good sign.
How is this billed, and why not fixed price?
Hourly, or as a monthly retainer for a set number of hours. There is no fixed deliverable to scope, so a fixed price would be a fiction.
Can I just ask one question?
Yes, and it is often the best use of this. A few hours on a decision you are about to commit to costs less than any of the ways it can go wrong.
What do we get, other than an opinion?
A written assessment of strengths, real risks, bottlenecks and a prioritised list of what to do about them, plus a session to walk through it and challenge it.
Will you write any code?
Some, where a prototype settles an argument faster than a document. If you mainly want delivery, a build engagement fits better and costs less.
Will you go around our engineers?
No. We work alongside your team to make them better at the decision, not to bypass them. Nothing lands as a recommendation your engineers first hear about in a slide.
What if the review says the plan is wrong?
Then the written assessment says so, with the reasoning. Agreement by default is the one outcome with no value.
Does a retainer mean you are on call?
No. It buys attention and availability, not an SLA. On-call for a running system is platform and infrastructure work.
Still have a question?
Ask it directly. You get a reply within one business day from the person who would do the work.