What happens if the scope changes mid-build?

Scope changes go through a written change order: what changes, what it costs, and what it does to the ship date, agreed before work continues. The original SOW never grows silently.

What if the build runs late?

Estimation risk sits with us. If we scoped the work and it takes longer, the invoice does not move. The exception is a scope change you approved, which is re-priced and re-dated in writing.

How can you fix a price before any code exists?

Because the scoping call and the written scope come first. When a system is inherited or too unclear to scope honestly, we say so and start with the paid systems audit instead of guessing a number.

What do you need from us during the build?

One decision-maker, a weekly review rhythm, and fast answers when a question is blocking. Slow decisions move dates; they never move the price.

Do you bill hourly instead?

No. Every engagement is fixed scope with a fixed number, or an honest recommendation that a different model fits you better, including one that is not ours.

You do, from day one. The repository lives in your GitHub org from kickoff, and handover includes a runbook your team can operate from.

FIXED PRICE

Fixed-Price Software Development

Scope, price, and ship date up front. Every Trenith engagement starts with a written scope and a fixed number. You approve the deliverables, the timeline, and the price before any code is written, and the invoice never grows because the calendar did. If we cannot scope it honestly, we say so before you pay anything.

Book a scoping callStart with a paid audit

WHAT GETS LOCKED

Three things, in a deliberate order: scope first, then price, then date. Anyone who gives you a number before a scope is guessing, and you pay for the guess later.

SCOPE

Locked at the SOW, after the scoping call

What will be built, what will not be built, and the assumptions both rest on, written in plain English. The scope document is the contract; nothing is priced before it exists.

PRICE

Fixed in the SOW, before any code

One number against the written scope. It changes only through a change order you sign, never because the calendar moved. Estimation risk sits with us, not with your budget.

SHIP DATE

Set against the milestones, tracked weekly

A date tied to the scoped milestones, reviewed in a weekly demo rhythm. If it ever moves, you know why, in writing, before it does.

FROM CALL TO SOW

01
Scoping call
Thirty minutes with a senior engineer. We map the workflow, the integrations, and the risks, and we tell you on the call if fixed price does not fit.
02
Written scope
Deliverables, exclusions, and assumptions, plus a milestone plan. This document becomes the statement of work both sides sign.
03
Fixed number and date
The SOW carries the price and the ship date. You approve both before work starts. Nothing begins on a verbal yes.
04
Build in the open
Weekly demos against the milestones. Scope moves only through a written change order, priced and dated before work continues.

WHEN THE AUDIT COMES FIRST

Inherited systems, half-finished builds, code nobody can explain: fixing a price on those is guessing. The paid systems audit buys one week of reading before anyone commits. You get a one-page architecture, a milestone plan, and a ranked list of risks, and the fixed price that follows is built on evidence. The report is yours whether or not we build next.

A one-page architecture of the system
A milestone plan with scope and sequence
A named list of the real risks, ranked

Start with the paid audit

WHEN FIXED PRICE IS THE WRONG MODEL

Fixed price is a tool, not a religion. These are the cases where we talk you out of it, and what we suggest instead.

A living product roadmap

Priorities that shift every week are roadmap work, not a scope. Fixing them in a contract just guarantees change orders. What we do instead: point you at the Monthly Engineering Retainer.

Research with no defined deliverable

When the real outcome is learning, a fixed scope is fiction. What we do instead: scope a time-boxed investigation with a written question to answer, or decline the work.

You need a team, not a project

Permanent embedded capacity is a hire, not a contract. What we do instead: say so on the call and tell you what we would look for in that hire.

A platform you cannot yet describe

Big, fuzzy systems cannot be honestly priced as one number. What we do instead: a paid audit, then per-phase fixed scopes. Never one giant figure on a fog bank.

PROOF

FAQ

Honest answers to the questions that show up most.

What happens if the scope changes mid-build?: Scope changes go through a written change order: what changes, what it costs, and what it does to the ship date, agreed before work continues. The original SOW never grows silently.
What if the build runs late?: Estimation risk sits with us. If we scoped the work and it takes longer, the invoice does not move. The exception is a scope change you approved, which is re-priced and re-dated in writing.
How can you fix a price before any code exists?: Because the scoping call and the written scope come first. When a system is inherited or too unclear to scope honestly, we say so and start with the paid systems audit instead of guessing a number.
What do you need from us during the build?: One decision-maker, a weekly review rhythm, and fast answers when a question is blocking. Slow decisions move dates; they never move the price.
Do you bill hourly instead?: No. Every engagement is fixed scope with a fixed number, or an honest recommendation that a different model fits you better, including one that is not ours.
Who owns the code?: You do, from day one. The repository lives in your GitHub org from kickoff, and handover includes a runbook your team can operate from.

Book a 30-minute scoping call.

Fixed scope. Fixed price. Or an honest "not a fit." A founder reads every message and replies within 4 business hours.

Fixed price vs. T&M →See real work →

Book a scoping call