Service 02 / Custom Applications
Software shaped like your actual process.
I build full-stack applications — database through interface — that replace spreadsheets, manual workflows, and three SaaS tools taped together. For businesses in Claremont and the Pomona Valley whose operations have outgrown the tools available off the shelf. You own the code, the data, and the infrastructure when it ships.
- Ownership
- Yours
- Pricing
- Fixed scope
- Based in
- Claremont
01 — What you get
What ships.
One system instead of five
The spreadsheet, the shared inbox, the manual copy-paste step, and the SaaS subscription nobody remembers buying — consolidated into something built for the way you actually work.
A trust boundary you can explain
The client expresses intent; the server decides what is true. Prices, permissions, and totals are never taken from the browser. That split is what keeps an application safe as it grows.
Tests around the money and the edges
Anything involving payment, permissions, or data loss gets automated coverage. The point is not a coverage number — it is that a change in year two does not quietly break something from year one.
Documentation written for your next developer
Architecture notes, decision records explaining why things are the way they are, and a working local setup. You are not buying a dependency on me.
02 — How it runs
Increments, against something real.
Phase 1
Map the process
I learn how the work happens now, including the parts people work around. Existing spreadsheets are the specification. You get a fixed scope and price from this.
Phase 2
Build the spine
Data model and the one workflow that carries the most weight, working end to end on a preview URL you can use. Everything after this hangs off a proven core.
Phase 3
Widen and hand over
Remaining workflows, admin surfaces, migration of live data, and training. Then support while your team gets used to it.
03 — Proof
Constraints resolved, not papered over.
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 — Where I work
Based in Claremont. Working across the Pomona Valley.
Application work needs more conversation than a website does — I have to understand a process before I can replace it. Being in Claremont means clients in Pomona, Upland, or San Dimas can walk me through how the work really happens instead of describing it over a call.
- Claremont, CA
- Pomona, CA
- La Verne, CA
- San Dimas, CA
- Upland, CA
- Montclair, CA
- Ontario, CA
- Rancho Cucamonga, CA
05 — 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?
It comes with you. Migration off spreadsheets, an old database, or a SaaS export is part of the build, not a separate project. Your existing records are usually the best specification available for how the software should behave.
What if the requirements change halfway through?
They will, and that is normal. Work runs in short increments against a live preview URL, so you see the thing working and change your mind based on something real instead of a mockup. Scope changes get repriced openly rather than absorbed silently and resented later.
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 does an application like this run on?
Boring, well-supported pieces: Nuxt for the interface, Postgres for data, Stripe when money moves, Sentry for error tracking, Playwright for tests. Nothing exotic. Exotic is what makes software unmaintainable after the person who chose it leaves.
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.
See also
01AI integrations
Practical AI inside a working system — retrieval, support, and content workflows that earn their keep rather than demo well.
Long-term support
What happens after launch: feature work, monitoring, and iteration with someone who already knows the codebase.