Situation 01 · /replace-spreadsheets
Your business runs on spreadsheets, email, and somebody's memory.
That worked until it didn't. I design and build the system that replaces the duct tape: scoped first, priced before code, and shaped around how your operation actually runs.
Sound familiar?
Five ways this shows up
- The quote sheet lives in one person's Excel, and pricing breaks when they are on vacation.
- Jobs get scheduled over text and email, then re-typed into two or three other places, and sometimes both versions are wrong.
- Nobody can say what is in progress right now without calling around, so the owner is the status dashboard.
- Every new hire learns the process by shadowing someone for a month, because the process exists only in people.
- You have looked at off-the-shelf tools, and every one of them fits about 70% of how you work. The other 30% is the part that makes you money.
Recognize yours?
The spreadsheets I replace
The quote sheet
The Excel that prices every job, guarded by the one person who understands it.
Becomes A quoting screen anyone can drive: current prices, protected margins, a quote out while the customer is still on the phone.
The dispatch board
The whiteboard or shared sheet that says who is where today.
Becomes A live dispatch view: jobs, crews, and status in one place, visible from the field.
The job tracker
The workbook that follows a job from first call to invoice, fed by re-typing from email.
Becomes One record per job, no re-typing, with a history you can search.
The hours collage
The timesheets nobody fully trusts at payroll.
Becomes Time tracking tied to jobs, so payroll and job costing stop arguing.
The month-end report
The spreadsheet one person assembles from exports, days after the month ends.
Becomes A report that is simply always current.
Yours isn't here?
Every operation has its own version of this. Describe yours, and I will tell you what it would become.
Tell me how yours runs →What I do about it
Mapped first, then built, then handed over
I do not start by building. I start by mapping how the work actually flows: who touches a job from first call to invoice, where the information lives at each step, and which of those steps actually need software. That takes two to three weeks, it has a fixed price, and it produces a plan you own.
The plan says what the system should do, what it should not do, what it will cost to build, and, in a decision memo, why each of those calls was made. Off-the-shelf beats custom for some pieces; when it does, the memo says so. And a battle-tested workbook is often the best spec I could ask for: when the right answer is a system behind your spreadsheet rather than instead of it, the memo says that too.
Then I build it, from my own plan, at my own estimate. Usually a focused core first: the quoting or the scheduling, whichever bleeds most, in production within weeks, then the rest in stages your team can absorb. It ships running: deployed, monitored, documented, and every account in your name. The person who mapped your operation is the person who writes the code, so nothing gets lost between the plan and the build.
wk 1 discovery and workflow mapping, wk 2 wireframes and architecture, wk 3 estimate and decision memo
- workflow map
- prioritized backlog
- wireframes
- architecture + estimate
- decision memo
staged releases, highest bleed first
in production, documented, accounts in your name
Fair questions
Asked by almost everyone in this situation
What if I only want the plan?
Then you stop after the scope stage and the plan is yours: it is written so any competent development shop can build from it, and the estimate gives you a fair benchmark for their quotes. Most clients have me build, and the engagement is designed for that. I price my own plan, so the estimate is mine to answer for, not a guess about someone else's spec.
We already got quotes from dev shops. Why is this different?
A quote from a vague brief is a guess with a signature. The dispersion in the quotes you got is the evidence: nobody knows what they are pricing yet. Scoping replaces the guess with a defined backlog, so the number at the end is attached to something specific, and I am the one who has to build to it.
Why not just buy off-the-shelf software?
Sometimes you should, and if that is my conclusion, the decision memo will say so and name the product. Custom earns its cost only where your workflow is genuinely different from what packaged tools assume, which is a thing scoping establishes instead of assuming.
What if my team won't stop using the spreadsheet?
Adoption is the biggest risk on this kind of project, and it is planned for like one: the system is shaped around the workflow your team already runs instead of one a tool imposes, the piece that bleeds most goes live first with a pilot group, and the old spreadsheet stays available, read-only, until nobody has opened it in a month. The risk register names this risk on day one, with its mitigation.
We like our spreadsheet. Do we have to give it up?
No, and sometimes you should not. Plenty of operations keep the sheet: as the calculation engine behind a secure web app, or as the familiar report surface a real system feeds automatically, so nobody re-types anything. The scope stage decides what the spreadsheet is in your case: the problem, the spec, or the interface.
Tell me how your operation runs today.
Describe the workflow that hurts most in three or four sentences. If I think a spreadsheet is still the right tool for it, I will tell you that too.
Start a conversation