When your tools almost fit, I build the missing part.
A spreadsheet that runs a process, data copied between systems by hand, a client portal you don’t have yet, or the first version of a product. I build web applications and integrations around how your team actually works, then test them, deploy them and hand them over.
It’s a short form: what you need, a few lines about the project, and your email. I read every inquiry myself and reply by email, usually within 24 hours.
- CRM, store or spreadsheetWhere the data starts
- IntegrationOne agreed source of truth for each record
- Internal toolThe screen your team works in
- A person approves
- Accounting or support deskWhere the result lands
What I build
Internal tools
Screens for the work your team does every day, such as order or case handling, scheduling, approvals and reporting, built on your data, with the permissions each role needs.
Client portals
A place where your customers log in to see status, documents or invoices, and send you what you need from them.
Integrations and data flows
Connections between your CRM, store, accounting, support desk and internal databases, with one agreed source of truth for each record, and retries and logs for when a connection fails.
First versions of products
An MVP scoped to the one journey you need to test with real users, with analytics set up before launch.
Dashboards and approval screens
One screen that shows what your workflows and automations are doing, and lets the right person approve or stop an action. More on dashboards & approvals.
Testing, deployment and handover
Automated tests for the parts that matter, deployment to the hosting we agree on, and documentation someone else can maintain it from.
How I build: I choose the stack for the job and for what your team can maintain afterwards. Public pages are built to Google’s Core Web Vitals thresholds: LCP of 2.5 seconds or less, INP of 200 milliseconds or less, CLS of 0.1 or less, measured on real visits at the 75th percentile. These are targets I check against, not guaranteed scores.
Before we start
- Someone who owns the process or product, and time with the people who’ll use it.
- Access to the systems, APIs and data the software touches.
- A definition of done: acceptance criteria we both agree before the build.
- Ownership: you own the code I write for your project. Internal tools I built before it stay mine.
- Support after launch is agreed separately.
- Not promised: compliance certification, uptime or speed guarantees. Where a project needs access controls, logging or a security review, they’re part of the agreed scope.
Why me for this
I talk to the people who use the tool, write the code and set up the deployment myself, so nothing gets lost between whoever gathered the requirements and whoever built it. My recent work includes B2B software connected to CRMs, data and approval steps.
Own work
This site’s inquiry flow
The form you’d use to contact me is part of this site: three steps, a Cloudflare Turnstile spam check, validation on the server, a task in my tracker for each inquiry, and a confirmation email. It’s my own business’s site, not a client project.
How we’d work together
I usually work for a fixed weekly rate. The work is scoped around a goal rather than a set number of days, and we agree the scope and terms for each project. They’re open to discussion. Discovery, the build and support after launch are agreed separately. Once we’ve agreed what “done” means, I’ll estimate how many weeks the build should take.
Questions
How long does a project take?
It depends on the scope. Once we’ve agreed what “done” means, I’ll estimate the number of weeks.
Can my team maintain it afterwards?
That’s the point of the handover: tests, documentation and code your developers can read.
Can you work with our existing systems?
Usually, if they have an API or a database I can be given access to. I check that access before we agree scope.
Further reading
Interfaces for workflows that run across several systems and need human decisions.
Articles and guides about this work. They explain methods and trade-offs; they aren’t case studies.
Describe the work, not the software
Tell me what the work is, who does it today, and which systems it touches. I’ll reply with questions and a suggested first step.