How we write a fixed-scope software proposal in 48 hours

Why we commit to 48 hours

Every project we take on starts the same way: a 30-minute discovery call, then a fixed-scope proposal within 48 hours. The proposal sets out scope, milestones, a delivery date and a price, in writing, before we write any code.

The deadline is short on purpose. While the call is fresh, the details are fresh too, and you can compare our answer with others while you are still deciding. A long gap between call and proposal usually means the scope was unclear, and a slow answer does not fix that. Clear questions on the call do.

The questions we ask on the 30-minute call

Before the call we read what you sent through the project form: the problem, who will use it, any existing code or designs, your budget range and your timeline. The call fills the gaps. We map the problem, the users, the constraints and what success looks like, using the same questions every time.

1. What is the goal? Not the feature list, the outcome. “Customers book and pay without calling us” tells us more than “a booking module”.
2. Who are the users? Customers, staff, admins, partners. Each role adds screens, permissions and tests, so we count them.
3. What must the first release do? We split must-haves from nice-to-haves out loud. If everything is a must-have, we ask what you would cut if the date moved.
4. What does it connect to? Payment providers, CRMs, ERPs, an existing API or database. Integrations carry most of the hidden risk, so we ask for documentation and test access early.
5. Is there a hard deadline? A trade show, a contract date or a season. We plan the milestones backwards from it.
6. What is the budget range? A range lets us propose the version of the project that fits, instead of guessing and missing.
7. Who decides? Who signs the proposal and who accepts each milestone. If those are different people, we want to know before the first demo, not after.

How the answers become a written scope

After the call, a senior engineer turns the notes into four lists. Every line should be something both sides can check, so we avoid words like “simple”, “fast” or “modern” unless they come with a number or an example.

• In scope. The features, screens, integrations and platforms we will deliver, written as user actions: “an admin can refund an order from the order screen”.
• Out of scope. The nice-to-haves from the call, plus anything a reader might reasonably assume is included. Writing these down prevents most later disagreements.
• Assumptions. What the price depends on: the third-party API behaves as documented, you supply content and brand assets, a named person answers questions within an agreed time.
• Acceptance criteria. How we both know a feature is finished. For example: “a customer can pay by card on staging, the order appears in the admin, and a confirmation email arrives”.

The same document records the technical choices and why we made them: the architecture, the stack, and trade-offs such as Inertia or Livewire for a Laravel app, or REST or gRPC for a Go API.

Milestones and what “done” means

We split the scope into milestones that each end in something you can use on a staging link, not a percentage of progress. Delivery runs in weekly sprints: plan, build, review, demo, with a staging link from day one and an update every Friday. You see each milestone working before you accept it.

A milestone is done when three things are true:

• Every acceptance criterion for it passes on staging, in a demo you have seen.
• The code is reviewed by a senior engineer and merged into your repository.
• The person named as decision-maker has accepted it in writing: a reply to our milestone email is enough.

The final milestone is launch and handover: the repository, documentation and deploy access are yours, and you own all of the code from the first commit.

What a proposal looks like: an example outline

1. The problem and the goal, in your words, so you can check we understood.
2. Users and roles.
3. Scope: in scope, out of scope and assumptions.
4. Architecture: stack, hosting on your own accounts, integrations and the reasons behind each choice.
5. Milestones, each with its acceptance criteria and a target week.
6. Delivery date.
7. Price and pricing model: fixed scope or time and materials, and a payment schedule we agree per project, for example tied to milestones.
8. How changes are handled.
9. After launch: handover, and the optional support retainer.

The proposal is a basis for discussion. It becomes binding only once both sides sign a separate written agreement.

Fixed price or time and materials

We offer two models. Fixed scope is one price for a clearly defined deliverable, agreed in writing before we start. Time and materials is a sprint rate for products that keep evolving. We recommend one after the discovery call, based on how much of the scope we can write down with confidence.

Fixed scope suits a first release, a new integration or a well-understood rebuild. Time and materials suits a product after launch, where next month’s priorities depend on what users do this month. Many projects use both: a fixed-scope first release, then time and materials once it is live.

A fixed price is only as good as the out-of-scope list next to it.

How change requests work

Weekly demos mean you will have new ideas. That is the point of them. On a fixed-scope project, each change goes through the same short loop:

1. You describe the change, in a demo or in writing.
2. We write down what it affects: scope, milestones, the delivery date and the price.
3. You choose: add it, swap it for something of similar size that is not built yet, or park it for after launch.
4. Nothing changes in the plan until you approve it in writing. Estimates for changes are free, and you get one within 3 to 5 working days.

Bugs are different. If a delivered feature does not meet its acceptance criteria, fixing it is part of the fixed price, not a change request. That covers anything you report within 15 days of accepting the milestone.

When there is too much uncertainty to fix a price

Sometimes 30 minutes is not enough to write a scope we would stand behind. The usual reasons are an existing codebase nobody has documented, an integration without a sandbox, or a goal that is still an idea rather than a product.

We say so in the proposal rather than pad the price. For an existing Laravel or Go codebase, the first step is usually a code audit, charged separately and done before we build anything: a review of the architecture, tests, security and performance. It usually takes 2 working days, and you get a written report and a plan. Most clients with an existing project ask for the audit first. For other unknowns, we fix the price of the parts we understand and put the rest on time and materials.

Summary

A fast proposal comes from asking the right questions on the call: goal, users, must-haves, integrations, deadlines, budget and who decides. We turn the answers into a written scope with clear boundaries, milestones you can see working, and a pricing model that fits how settled the project is.

If you have a project in mind, send us a short brief. It takes about two minutes, and the fixed-scope proposal follows within 48 hours of the call.

Frequently asked questions