How we work - A clear path from business problem to working software
You'll always know where your project stands. The path from “here's our problem” to software your team relies on is short, and you see working results every week along the way.
Understand
Every project starts with a conversation about your business, not about technology. What does the work actually look like day to day? Where does time disappear? What breaks, and what does it cost when it does?
From there I map the workflow we're fixing and write up a written scope: what we're building, what we're deliberately not building yet, what it costs, and how long it takes. Wherever possible I quote a fixed scope at a fixed price.
This is also where I'll tell you if you shouldn't hire me. If an off-the-shelf tool solves your problem for $40 a month, you deserve to know that before you spend real money on custom software.
Included in this phase
- Free initial consultation
- Workflow mapping
- Build-vs-buy recommendation
- Written scope and fixed quote
Build
Work happens in short cycles with something visible at the end of each one. You're looking at real screens and real data within the first couple of weeks instead of waiting until the end to see anything.
You get a short progress update every week: what got done, what's next, and anything I need from you. Questions get answered by the person writing the code, usually the same business day.
Scope changes are handled honestly. Small adjustments are part of the work. If something genuinely changes the size of the project, you get the cost and timeline impact in writing before I build it, and you decide.
Deliver & support
We plan launch around your business calendar: a quiet season, a weekend, whatever causes the least disruption. We test with your real data and your real team before anything goes live, and I'm around for the switchover and the first days after it.
You get everything: the code, the accounts, the credentials, and documentation written for whoever comes after me. If you ever want another developer to take over, they'll have what they need.
After launch, support can be handled through a small monthly arrangement or scheduled as needed for fixes, changes, and questions.
Included in this phase
- Testing with real data. Software gets tested against your actual workflows and edge cases before launch, with your team involved, so day one is boring in the best way.
- Full ownership. Code, accounts, credentials, and documentation are yours from day one. You could leave at any point and take all of it with you.
- Support that fits. A monthly support arrangement if you want a standing safety net, or hourly help when you need it. Retainers are optional.
Principles - The rules the work follows
These are the standards I hold the work to, and you should hold me to them too.
- Honest scoping. The estimate you get is the estimate I believe, including the parts that are uncertain. Bad news early beats bad news late.
- Boring technology. Proven tools over shiny ones. Your business software should be built on technology that will still be supported in ten years.
- Small releases. Working software early and often, so course corrections happen when they're cheap instead of when they're painful.
- Business before technology. Technical decisions are explained through their effect on cost, risk, timelines, and the way your team works.
- Your ownership. Everything built for you belongs to you: code, data, accounts, documentation. It should always be easy to walk away with everything in hand.
- Maintainable first. Every line is written knowing someone else may maintain it someday. That discipline is what makes software cheap to change later.
Tell me what is slowing your business down
A short description of the workflow, the systems involved, and the current workaround is enough to start. I'll reply within one business day.
Based in
- Seattle, WA
Working remotely with clients
across the US