How a project gets priced

The same “portal” can be a news listing or the place where a thousand clients see what they owe. Pricing the first at the cost of the second, or the other way around, is where projects that stall halfway come from. A public rate card forces that trap.

We prefer a short conversation and a proposal that can be discussed line by line. If the job can't be scoped in that conversation, we say so. The next step, if needed, is a discovery phase with an end date whose only deliverable is the written scope. It isn't an open-ended phase for thinking out loud, and it's paid because it's work.

There's no honest starting price that fits everyone. In the first conversation we tell you whether it's a fit and what would need narrowing to give a figure. A number without that text doesn't hold up, and we don't send it.

The figure moves with how many roles see different data. A shared login isn't the same as a sales rep who can't see the margin, a client who sees only their own data and a finance team that can reopen a period. Every real permission is work. “Everyone sees everything” is cheaper and usually wrong.

Connecting to an existing system moves the figure, and it moves more if that system doesn't allow what the process needs. So does a station that works offline or with a device, an app published in a public store or only inside the company, and AI that publishes on its own or stays a draft because mistakes are expensive. Who installs it, and on which fleet, is another line: not a last-week detail.

None of this is translated into euros here. It's translated into questions. If the first message already brings those answers, the proposal can include a figure. If not, the first reply is a question, not a discount.

A fixed-scope project works when the piece can be named: this screen, this workflow, this integration, this app. The price covers that. A new idea that shows up in week three doesn't get in out of goodwill. It's noted and we decide whether it's another engagement.

Ongoing support works when the first delivery will keep being adjusted because the team is still learning what it needs. That's written down too: what kind of change fits and what no longer does. “We're available” isn't a pricing model. Loose hours, without knowing which system needs touching, aren't either.

Maintenance, on-call, app stores and changes to a tax rule each get their own line if you want them. Watching errors, backups and certificates isn't the same as building the first version. Folding it into an “all-inclusive” is how it gets argued about later, angrily.

The list of what gets built. The list of what's left out, just as visible. The moments when someone outside the meetings sees it. What's delivered at the end: code, access, a deployment guide and a session with the people who will use it.

Code and accounts stay in the company's name in every format. On the web, that's the repository, the domain and the deployment. On desktop, the installer and the build process. On mobile, the binary and the decision between app store and internal distribution. In AI, the workflow and the revocable credential, not a chat with the password inside.

If a system that also needs touching appears mid-project, we stop and decide. The proposal isn't an envelope opened at the end. It's the text both sides can repeat in the same words halfway through.

The first release is small and usable. If nobody uses it, the second one doesn't get built. That rule protects the company from paying for a full map and protects us from building on a dead hypothesis. Carrying on by inertia is how a one-screen scope turns into a program nobody opens.

The proposal's dates are about showing, not just “development finished”. A finished tool nobody has seen until the last Friday isn't finished. It's hidden. The calendar names the day someone at the station, in the field or at the inbox uses it.