Service 02
Software shaped like your actual process.
I build full-stack applications — database through interface — for businesses in Claremont and the Pomona Valley whose operations have outgrown off-the-shelf tools. The work might replace a fragile spreadsheet or connect systems that currently depend on manual handoffs. You own the code, data, and infrastructure when it ships.
- Ownership
- Yours
- Pricing
- Fixed scope
- Based in
- Claremont
01 — What you get
What ships.
Fewer handoffs and repeated entries
When information has to be copied between a spreadsheet, a shared inbox, and a business tool, every handoff needs someone to keep it moving. I build the missing workflow, connecting useful systems or replacing the parts that no longer fit.
Money and permissions handled safely
The browser can ask for an action; it does not decide prices, totals, or who has access. Those checks happen on the server, where they can be tested and changed without trusting every screen in the app.
A system your next developer can take over
Payments, permissions, and data changes get automated tests. The code and its decisions are documented so a handover next year is ordinary work, not an excavation.
02 — How it runs
Review the workflow while I build it.
Phase 1
Map the process
I learn how the work happens now, including the parts people work around. Your records, the people using them, and the exceptions they handle inform the specification. You get a fixed scope and price from this.
Phase 2
Get the core workflow working
The data model and the workflow that carries the most weight, working end to end on a preview URL you can use. You can try the core process before we build the remaining workflows.
Phase 3
Complete the workflows and hand over
Remaining workflows, admin surfaces, migration of live data, and training. Then support while your team gets used to it.
03 — Proof
Price changes without losing order history.
Stripe prices cannot be edited in place. The Mendivil catalog needed owners to change prices anyway. So a price change creates a new price, promotes it to the product's only active one, and retires the old — historical orders keep what they were charged, and the owner sees a single field. That is what this work is: finding the design that satisfies a hard constraint without pushing it onto the person using the software.
Read the case study04 — Questions
Before you ask.
How do I know I need custom software instead of an off-the-shelf tool?
If a SaaS product does the job, buy it — I will tell you so. Custom is worth it when your process is the thing that makes you money and no product matches it, or when you are paying for four tools and still exporting to a spreadsheet to make them talk. The tell is usually a spreadsheet nobody is allowed to break.
What happens to the data we already have?
We scope the migration alongside the application, whether your records come from spreadsheets, an old database, or a SaaS export. Those records show how the work happens today. We also account for permissions, exceptions, and business rules that live outside the spreadsheet, so the new system can carry the work forward.
What if the requirements change halfway through?
That is normal. Work runs in short increments against a live preview URL, so you can try the workflow and make decisions based on working software. If a change affects scope, we agree the revised cost and timing before I build it.
Who owns the code?
You do. It lives in a repository you control, on infrastructure in your accounts, with no license back to me and no dependency on my continued involvement. If you want to hire someone else next year, they can read it — that is what the tests and the documentation are for.
What are you working around?
The best starting point is usually the thing your team has quietly built a workaround for. Tell me what that is and what it costs you, and I will tell you whether it is worth building software for — including when the answer is no.