What an app quote pays for before the first line of code

We recently prepared a quote for a custom booking engine. The project came through an agency whose owner we know. We had talked for a while about working together on something, and this looked like the project. The agency had built the client’s presentation website, and next to it the booking interface the client was using looked very poor.

The client already had a booking engine running in real operation, with its provider’s default interface, and wanted to replace that interface with one designed for their customers. A professional designer from the agency delivered the design, and the agency’s owner wanted us to build the engine. The plan was about two months of work.

The designer worked toward one thing the whole time: that the people booking through it get where they want to go quickly and without confusion.

By the time the quote went out, we had spent about forty hours on it, before writing a single line of code.

We started where every project like this should start: with the documentation of the booking engine’s provider. Before there was a single new screen, we found out what its system allows, what it does not, and what it expects from a new interface. We were looking for the things that must not slip past us at the beginning.

Those things are cheapest to deal with on the first day. Found a month into the build, they cost the most, because the new interface has to fit into the running system without breaking anything the business relies on every day.

The rest of those hours went into questions you cannot see on the finished screens. How people find the booking page, on Google and through the AI assistants they now ask instead of searching. How fast every step has to be, because when something takes long, people leave. And how much the systems in the background can take before they stop answering.

None of these questions has a simple answer. The limits are set by the technology the project has to be built on, and what you gain in one place is often lost in another.

That is why the decisions have to be made early, and why they take time.

One example shows what such a decision looks like. The provider limits how many requests the booking engine may send it in a given time. That limit is not counted for each location separately. It covers the whole brand at once.

Every customer looking for a free slot sends a request. On a busy afternoon, an interface that asks the provider about everything, every time, could use up the limit of the whole brand, and then nobody could book in any location. So we decided which answers the system can remember for a while and use again, and which it has to ask for fresh every time.

Nobody will see this decision on the finished screens. If it were missing, everyone would.

After the client received the quote and a detailed time estimate, the agency’s owner called us: the work would not be ours after all. The client had chosen someone they knew, who started on it straight away.

A month later, the result looks quite different from the designer’s work, so a lot of her time and work was simply set aside. Several of the questions above have already been answered in ways we decided against during those forty hours, because of the limits of the technology underneath. How it turns out, we will see.

The quote the client saw was already a trimmed one. It was written out by phases, and when it looked like a lot, we cut it by more than half. What was left was no longer the finished product, only a minimal MVP: no tests, no checks that it works, no protection.

On paper that made it cheaper. In practice those are the parts a client only notices when something goes wrong.

We will not cut a quote like that again, because we know what is behind those numbers.

We put more hours into that analysis than a quote usually gets. We know the agency’s owner and wanted to deliver professional work however it turned out, so we did not ask to be paid for the analysis. A client we did not know, we would ask. Forty hours of reading documentation and making decisions is work, whoever ends up writing the code.

And when a client says a quote is too expensive, we stand behind it. The numbers come from experience, not from wanting the job at any price.

When a client compares quotes, the cheapest one is the easiest to pick. It does not always turn out the cheapest. A quote without the decisions costs less at the start, and the difference is paid later, when the problems those decisions would have prevented come out.

A cheaper start is not a cheaper project.

Anyone can build an app now, and build it fast. Tools like Codex and Claude Code have made that real. But the client still has to know what to build, and someone still has to make the decisions that keep it working.

There is a saying that fits.

You can draw a tattoo yourself, but if you want it done properly, you go to a tattoo artist.

A quote from someone who spent the forty hours is the price of having it done properly.