How We Scope a Geospatial Project in Two Weeks

Forty pages is a normal length for a geospatial proposal that has never touched a thousand rows of the client's data. We stopped writing those. Our smallest engagement runs two weeks, and it starts with a sample of your real files and ends with a thin slice of working software against your actual pipeline.

The claim this post defends: for most geospatial work, two weeks of discovery on real data beats a traditional proposal at guessing what you think you need. A proposal is written to be approved. A scoping sprint is built to be proven wrong, and being proven wrong in week one is the cheapest failure you will ever buy.

A quote written before the data arrives prices a fiction

Here is how the fiction compounds. A product owner describes a routing feature across two video calls: geocode customer addresses and color a delivery map by delay. The proposal prices geocoding as a solved problem, and why not, every vendor sells it. In week four of the build the data finally arrives, and a quarter of the addresses fail to match because the postal codes in one country are years out of date. Nobody priced that archaeology. The quote said six weeks, the quote was sincere, and sincerity is not knowledge.

The pattern generalizes past postal codes. Road networks carry closed segments nobody maintains in the source. Fleet traces arrive in local time from half the vehicles and UTC from the rest. Each of those is invisible until an engineer's code meets the file, and every one of them was knowable in week one for the price of one load.

What we ask to see before we name a number

The first ask is the data itself, a sample on day one, not a data dictionary in week three. Even 1,000 records will usually show what a thousand slides never will, like coordinate columns swapped or street encodings that break on accented names. A data dictionary describes what the data should be. The sample tells us what it is.

Then comes the rest, because data is only one of four things a blind quote has to assume.

What we ask for	What it changes
A sample of the real data, even 1,000 records	Projections and encodings surface in the first load instead of the ninth meeting
Where the result has to run	A cloud pipeline and an offline browser on a trailhead laptop are different disciplines
The name of the one person who signs off	One name is a specification; a committee is a stall
Your definition of "done", stated operationally	"Better delivery estimates" is a mood. "Dispatchers stop phoning drivers about late arrivals" is a test

The sign-off question surprises people, and it belongs on every scope. Quotes written for a committee die in a committee, quietly, on a budget you have already committed. One named person who owns the acceptance test and the change process: that is what turns a scoping document into an agreement anyone can actually act on.

Operational definitions of done matter for the same reason. If nobody can say what the user stops doing when the thing works, then nobody can verify the project did anything, and the dispute at handover will be about opinions instead of behavior. A single testable sentence costs ten minutes and saves the argument.

The two promises we refuse to make

The first is any pledge shaped like "AI will cut your manual work by 80%." An agent watching failed validation logs can plausibly absorb most of an engineer's triage load, and the pattern is well established. The specific percentage depends on how much of your failure volume actually needs human judgment, and the only way to learn that is to measure it. So the honest version of the promise is a measurement plan: capture your baseline first, run a pilot against it, then report what moved. We will not quote the number before the baseline exists, and a vendor who will is guessing on your budget.

The second is a timeline written before someone has parsed your files. Any schedule built without loading a sample of the data is fiction wearing a Gantt chart. We will give you a budget range on the first call anyway, because a wide range stated plainly is fair. We narrow it in week two, once the slice is running and the surprises have a shape.

The lighter version that fails in one decisive place

We keep sketching a cheaper version of all this: a structured questionnaire, answers by email, quote by Thursday. It fails in exactly one place, and the place is decisive. Run it in your head. The form asks how many records you hold, and the answer comes back "about 10,000." The load takes two hours and returns 380,000 records, because a migration multiplied the volume almost forty times last spring and nobody filling in the form knew. Nothing in that gap is dishonest. A questionnaire measures intent, and data measures data. The lighter version stays on paper, and two weeks stays two weeks.

Week one on the data, week two as one slice through it

Discovery is not requirements interviews. The engineer who will build the thing spends the week loading your real inputs, the address tables, the fleet traces, whatever the job actually runs on. The output you should expect by Friday is two artifacts: a ranked list of the remaining unknowns with a cost written next to each, and a measured baseline for whatever the project promises to improve. That baseline is the thing that makes every later percentage honest.

Week two builds one vertical slice, a thin path through the real stack from real input to visible output. If the project is delivery routing, the slice is a handful of your addresses geocoded and one route computed on your own road network, rendered in your app's own stack. The slice has no login screen, no polish, and no configuration. What it has is the answer a proposal cannot give: does the approach hold up against the pipeline you actually own. It also prices the invisible work early. When your sample turns out to need a deduplication pass before any geocoder can touch it, week two costs the estimate one line item, while the number is still negotiable.

The person who quotes you should be the person who builds

In a large firm, the person who prices your project often meets your data for the first time after you have signed. Every handoff between estimator and builder loses a little fidelity, and the losses compound in one direction: the estimate stays optimistic while the build discovers the truth. On a team our size, the quote is written by the hands that will load the data, so the number carries what the data taught. That is structure, not virtue; there is no account manager positioned between the estimate and the consequences, which is precisely the accountability you are paying for when you hire small.

When you genuinely need a fixed price

Scope-first has a blind spot, and it is procurement. If your budget cycle requires a fixed commitment before anything moves, a two-week sprint that ends in "now we can discuss numbers" does not work for you, and we will not pretend otherwise. Our way out: run the scoping sprint anyway, at a fraction of the build cost. Then write the fixed quote afterward against what week one actually proved, with the contingency disclosed as its own line item. If your process rules forbid even the sprint, do this instead: make every bidding vendor name, in writing, the assumptions their fixed price rests on and who owns the risk when a guess turns out wrong. A vendor who answers that exercise with silent assumptions dressed as certainties has told you about the bid more than any reference call would have.

The takeaway: before you compare proposals, ask each vendor one question, what they would need to see before committing to a number. Then send it to them. Whoever quotes without loading your data is selling you a bet; whoever asks for the sample first is selling you a measurement. Both are legal. Only one of them is worth financing.

AngoraTek is a small geospatial consultancy. If you are about to fund something like this, talk to us, and bring the data sample with you.