Internal CRMs and ops platforms
Contacts, locations, jobs, and the fields your team actually uses — without paying for a suite of modules you never open.
Custom software
Stop Paying for Software You Barely Use.
Replace fragmented SaaS subscriptions, spreadsheets, and manual workflows with purpose-built applications designed around how your business operates.
What this looks like in practice
The useful replacements are usually narrow. A tracking system. A portal. An approval path. Not a new ERP.
Partner and vendor portals
A shared place for status, requests, and handoffs so coordination does not live in email threads and spreadsheets.
Approvals, requests, and reporting
Request-management systems, custom reporting, and workflow apps built around the rules you already run by hand.
Software I have already shipped
Selected systems built in operating roles, not concept decks.
Partner operations
Partner operations portal
Custom platform connecting external partners with internal operations across 15 shops, replacing fragmented coordination.
400+jobs supported
Shop operations
Inventory, RMA, and parts requests
Weekly attestation, keep-versus-return recommendations, automatic RMA paths, and a parts-request form that recorded 518 structured entries with supply-defect flags.
$200K+excess inventory identified
Internal tools
About 30 systems in production
Mostly operations tooling at RepairWise / Fixlane in the last year: claims, parts and RMA tracking, labor coding, partner and shop management. Built, deployed, and maintained — not handed off as a prototype.
30internal tools
When a custom app is the right cut
The point is not to become a generic app shop. The point is understanding the operation well enough to replace a $50K/year SaaS tool with a smaller application that matches the work.
- The current subscription is expensive relative to how much of it you use
- The data model is straightforward: records, statuses, owners, and a few integrations
- Ongoing maintenance is something the business can live with
- The pain is the workflow, not a missing enterprise module
If the system is already a good fit and the waste is in the handoffs, the better move is often to connect what you have. I will say so.
How a build typically runs
Same path as the rest of the work: scope, smallest version, real workflow, then production.
1
Scope
What the team does today, which fields matter, which systems must stay, and what can be left out of v1.
2
Data model
Records, statuses, permissions, and the exception path. Integrations only where they earn their keep.
3
Build
Interface, workflow, and the few connections the operation actually needs. Claude and other AI tools are in the stack when they reduce build time or handle document work.
4
Deploy
Ship it, watch how people use it, and keep it running. Some projects start with a short paid discovery if the workflow is still unclear.
Common questions
Do we need to replace our existing software?
Sometimes. If a tool is expensive, barely used, or forcing a workflow that does not match the business, a purpose-built app can be the cheaper, clearer path. That is the exception that is worth taking, not a rule that every system should be rewritten.
The fit is bounded applications: straightforward data models, limited integrations, and maintenance you can actually own. If the current system works and the waste is in the handoffs, connecting what you already have is still the right answer.
Can every business tool be replaced cheaply?
No. Broad platforms, messy data, and heavy integration surfaces are usually a poor custom-build. I look for a thin cut of the work, not a replica of the vendor product.
What do you actually build with?
Recent production systems have used Next.js, TypeScript, Supabase, MotherDuck, Python, Mapbox, and Claude. Replit is one environment I have shipped in — see Replit implementation if that is your stack.
Have a workflow that does not fit the software you bought?
Describe the process and the tools around it. I will tell you whether a custom app is worth building.
Discuss a Project