Answers
The questions worth asking before hiring anyone to build your software, answered in writing rather than on a call.
| Questions | 57 |
|---|---|
| Not here? | Ask it directly |
How work is scoped, quoted and paid for.
What does it cost?
For project work, every engagement is quoted before it starts so you know the number in advance: an MVP week is a fixed price, and larger builds are quoted per phase. Consultancy runs on an hourly or day rate agreed up front. We do not publish rates because the honest answer depends on what you need, and a rate card mostly invites the wrong conversation.
Do you work fixed price or hourly?
Both, depending on the shape of the work. A build with a definable outcome is quoted as a fixed price against a written scope, which puts the estimating risk on us rather than on you. Consultancy is billed hourly or at a day rate, covering architecture review, working alongside your engineers and advisory time, because there is no fixed deliverable to scope and pretending otherwise helps nobody.
What if the work turns out bigger than the scope?
If we misjudged the estimate, that is our cost and we finish the agreed scope anyway. If you add to the scope, we price the addition before starting it. Nothing gets billed as a surprise.
Do you take equity instead of fees?
Not as a rule. We have built enough products to know that equity in an unproven idea is not payment. For the right project we will discuss a mix, but the default is cash for work.
How do we start?
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 there a minimum engagement?
For a build, the smallest useful piece of work is an MVP week. Consultancy has no real minimum. A few hours on an architecture decision is a perfectly reasonable 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 is yours, the intellectual property is yours, and there is no licence back to us. We keep no rights over what we build for you.
Who owns the infrastructure?
You do. Everything is provisioned in your own cloud accounts under your own billing, including the domain. We work inside your accounts rather than hosting anything on our side.
Is there any lock-in?
None. No licence, no hosting, no required retainer, and no proprietary framework you can only maintain through us. If the handover leaves you unable to run your own product, the engagement has failed.
What does handover include?
A documented repository, the decisions written down with their reasoning, a walkthrough with whoever will maintain it, and an honest note on what to build next and what we deliberately left out.
Do you offer support afterwards?
We can, on a retainer, and plenty of clients take it. But it is optional by design. The code is conventional and documented precisely so that another engineer can take over without us.
What if we hire our own engineers later?
That is the intended ending. We will help onboard them, and the code is written to be readable by someone who was not there when it was built.
What if we are not happy with the result?
Because you see a working deploy at the end of every day, there is no scenario where the first time you see it is at the end. If it is going wrong, you will know on day two and we will 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 existing team?
Yes, and it is often the best version. We can take one part of the product and stay out of the rest, or set up the platform and practices and hand them back. We will not quietly become a dependency you cannot remove.
Can you work in our existing codebase?
Usually. We will read it first and tell you honestly whether building on it is cheaper than replacing the part in question. Sometimes the answer is that it is not, and we would rather say so up front.
What timezone are you in?
Taipei, with regular working hours overlapping Europe. In practice that means 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. If nobody on your side can make a decision within a day, the timeline stretches, and that is the one dependency we cannot absorb.
How do we communicate?
Slack or email for the day-to-day, a short call when a decision needs one, and a working deploy you can open at the end of each day. No status meetings that exist to produce a status.
Do you bring in other people?
When a project genuinely needs a designer or a specialist in a domain we do not own, we bring one in and tell you. What we will not do is subcontract the build and stay on as a layer of project management.
How AI is actually used in the work, and how your systems are handled.
What does "AI-first" actually mean here?
One person sets 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, and anyone claiming otherwise at this volume is bluffing. Review is aimed where being wrong is expensive: the data model, the interfaces between parts, and anything touching money, authentication or data loss. The rest is held by types, tests, and a narrow set of conventions the agents are held to. That is also roughly how review works on any team large enough that one person cannot read everything.
Is the code written by AI any good?
An agent's output is a draft, and it is read by someone who has run production systems for fifteen years and knows what fails at three in the morning. The code comes out conventional, tested and documented, because generation being cheap removes the usual excuse for skipping those.
Will you use AI where it does not belong?
No, and we will tell you when a plain script beats a language model. Where correctness matters more than flexibility, in billing, compliance, or anything that reconciles, we keep the model out of the path.
Does our code get sent to AI providers?
Code is processed by the coding tools we use to build your product. We will tell you which providers are involved before starting, and if your agreements prohibit it, we work without them and quote accordingly.
How do you handle our credentials?
We work in your accounts with scoped credentials you issue and can revoke. Secrets stay in a manager rather than in a repository or a chat message, and access ends when the engagement does.
Do you sign NDAs?
Yes, routinely, and before you send anything sensitive. Several projects in the case studies are covered by one, which is why some are described without naming the client.
What about agents reading our company data?
Agents read through views that exclude what they should not see, so the boundary is enforced in the tool layer rather than by asking the model nicely. We document exactly what is exposed before anything is built.
Five working days from a scoped idea to a deployed product with real users able to sign in and use it. Fixed scope, fixed price, agreed before anyone writes code. Read the full page.
Is a week really enough?
For one sharp flow, yes. The constraint that makes it work is scope: we agree on the single thing that proves the idea and build that properly, rather than half-building ten features. If your idea needs more, we will say so before you pay.
What happens if it slips?
The scope is fixed at the start and the price with it. If we misjudge the estimate that is our problem, not yours, and we finish the agreed scope anyway.
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 are still running on that original codebase.
Who owns it?
You do, from day one. The repository, the cloud account and the domain are yours. There is no licence, no hosting lock-in and no retainer required afterwards.
What do you need from me?
About two hours on day one to settle scope, then a daily review of what shipped. If you cannot make the reviews, the week takes longer.
We take the internal work that eats hours every week (triage, lookups, reporting, routing, drafting) and wire agents into your real systems so it happens without anyone doing it by hand. Read the full page.
What can you actually automate?
Internal processes with a clear input and a clear output. Support triage, data lookups across systems, recurring reports, routing and assignment, first-draft writing. If a person does it the same way every time, it is a candidate.
Will it make things up?
Any language model can. We reduce it by grounding agents in your own data and by using plain automation wherever correctness matters more than flexibility. We will tell you which parts of a workflow are safe to hand over and which are not.
Where does our data go?
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 built this before?
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?
Then we will probably tell you to keep it. This is worth building when the value is in the connections to your own systems, which is exactly what a generic tool cannot reach.
The whole build, owned by one party. Data model, backend, interface, infrastructure and deploy, delivered as a product your own team can pick up and keep running. 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 genuinely needs it.
Can you work with our designer?
Yes, and we would prefer to. We can build to finished designs, or take a rough direction and make the interface feel considered ourselves.
What if we hire an engineering team later?
Good. That is the intended ending. The code is conventional and documented precisely so a new team can take it over without a rewrite, and we will 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.
How is this priced?
Build work is scoped and quoted per phase, so you know what a phase costs before it starts. If what you actually need is consultancy rather than delivery, that is billed hourly instead, and we will say so rather than force a scope around it.
Someone to own the boring-critical layer, so your engineers ship features instead of fighting the platform. Cloud, pipelines, reliability and the monthly bill. Read the full page.
What kind of infrastructure?
Cloud-native and serverless. Production on Cloudflare's edge and on the usual providers, from a single service to a platform serving a global audience across multiple regions.
Ongoing or one-off?
Either. We can own it on a retainer, or come in for 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 available as backup at whatever level you want.
Do you take on-call?
We can cover it during an engagement where that makes sense. The longer-term aim is monitoring and runbooks that make on-call manageable for your own team.
What does a cost cleanup usually find?
Oversized instances, forgotten environments, data leaving a region for no reason, and logging retained far longer than anyone needs. The first pass typically pays for itself.
A good developer optimises for shipping this week. This is for the questions above that: whether this week's shortcut still works next year, and what it costs when it does not. Architecture review, technical due diligence, and standing access to a second opinion, billed by the hour. Read the full page.
Our developer says they can handle the architecture. Isn't that enough?
Often it is, and if so we will tell you rather than sell you hours. A good developer makes sound decisions inside the frame they have been given. The open question is who sets that frame, and whether anyone is asking if this week's shortcut still works next year. If your developer is doing both jobs well, you do not need this.
Do we need a CTO?
Most companies asking that question do not need a full-time one yet, and hiring early is expensive in both salary and equity. What they need is someone senior asking the compounding questions a few hours a month. If you reach the point where the honest answer is a full-time CTO, that is a good sign and we will say so.
How is this billed?
Hourly, or as a monthly retainer for a set number of hours if you want standing access. There is no fixed deliverable to scope, so pricing it as a fixed project 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 is cheaper than any of the ways that decision can go wrong.
What does a review produce?
A written assessment covering strengths, real risks, bottlenecks, and a prioritised list of what to do about them, plus a session to walk through it and be challenged on 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 is the honest fit and costs you less.
Do you work with our existing team?
That is the usual shape. We are there to make your engineers better at the decision, not to go around them. Nothing lands as a recommendation your team first hears about in a slide.
What if the review says the plan is wrong?
Then it says so. Paying for an outside opinion and getting agreement by default is the one outcome with no value.
Is a retainer a support contract?
No. It buys attention and availability, not an SLA. If you need someone on call for a running system, that 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.