I do not know whether I need a web app, a mobile app, or a spreadsheet fixed.

That is a normal starting point and part of what the first conversation is for. Describe the process and where it breaks. The recommendation sometimes is not to build software at all — configuring something that already exists is often cheaper and faster, and I would rather say so early.

Can you work with our existing codebase?

Usually. I would start by reading it and giving you an honest account of its state, what is safe to build on, and what is going to fight back. That review is useful on its own even if the build goes elsewhere.

How is custom software priced?

By scoped phase rather than one number for an unbounded project. The first release is estimated in detail; later phases are estimated once the first is in use and the unknowns have shrunk. Running costs such as hosting, third-party services and support are separated from build cost so you can see both.

What happens if we want to take it in-house later?

You own the source, the infrastructure configuration and the documentation throughout. Handover is a planned step, not a renegotiation. Building it so a future developer can pick it up is part of the job, not a favour.

Do you only build things with AI in them?

No. AI is one tool among several and a bad fit for plenty of problems. A scheduling tool, a customer portal or a data import usually needs correctness and clear rules, not a language model. Where AI genuinely helps, I build it with the budgets, verification and escalation my independent projects demonstrate.

You know what the business needs. You do not need to know the stack.

Custom software development

Bespoke software built around one business problem: web applications, internal tools, iPhone apps, and the integrations between them. The technology is chosen after the problem is understood, not before.

The situation

Most software problems arrive described as a tool: a spreadsheet that four people edit at once, an off-the-shelf product that does eighty percent of the job, a process that only one member of staff fully understands. The useful first conversation is not about frameworks. It is about what currently goes wrong, how often, and what it costs when it does.

This is the page for work that does not fit a narrower category. It covers web applications, internal and admin tools, customer-facing portals, iPhone apps, data imports, and the unglamorous integration work between systems that already exist. AI appears in a project here only where it does a job a simpler approach would do worse.

You work directly with the engineer writing the code. There is no account manager between the description of the problem and the person solving it, and no team of three billed against a project that needs one.

How I approach it

Start at the cost, not the feature list

The first session establishes what the current process costs in hours, errors, or lost work, and what a fixed version is worth. A feature list written before that is a guess. Some of these conversations end with a recommendation to configure an existing product instead of building anything, which is a cheaper outcome than discovering it in month three.

Ship the smallest version that is genuinely used

The first release targets the narrowest slice that removes real work, put in front of the people who do that work. Software nobody has used is a hypothesis. Usage is what turns the rest of the plan from speculation into a queue ordered by evidence.

Choose boring technology on purpose

Stack choices follow the problem and the maintenance horizon. A tool three people use internally has different constraints from a public product with a signup flow. I favour widely understood technology so that the next developer to open the project — possibly not me — can work in it without a translation layer.

Hand over something maintainable

You receive the source, the deployment path, the environment configuration, and written notes on how it runs and how it fails. The engagement is designed to be leavable. Software you cannot hand to someone else is a dependency, not an asset.

What gets delivered

A scoped build with a named first release
Web application, internal tool, or iPhone app as the problem requires
Integrations with the systems you already run
Deployment, environment configuration and a runbook
Source code and handover notes you own outright

What it costs to get wrong

A year of build against a specification nobody validated, delivered to users who had already worked around the problem.
A system only its original developer can change, so every small edit becomes a negotiation.
An integration that silently stops syncing, discovered when the numbers stop matching.
A handover with no documentation, where the running service and the source code have quietly diverged.

Why you can believe this

Eight iPhone apps of mine are live on the App Store, each taken from first commit through review to release. The client work behind this site is under NDA and described without naming the client, which is the same confidentiality any project here would be given.

Explore the work Read the ai-os case study

Questions buyers ask

I do not know whether I need a web app, a mobile app, or a spreadsheet fixed.: That is a normal starting point and part of what the first conversation is for. Describe the process and where it breaks. The recommendation sometimes is not to build software at all — configuring something that already exists is often cheaper and faster, and I would rather say so early.
Can you work with our existing codebase?: Usually. I would start by reading it and giving you an honest account of its state, what is safe to build on, and what is going to fight back. That review is useful on its own even if the build goes elsewhere.
How is custom software priced?: By scoped phase rather than one number for an unbounded project. The first release is estimated in detail; later phases are estimated once the first is in use and the unknowns have shrunk. Running costs such as hosting, third-party services and support are separated from build cost so you can see both.
What happens if we want to take it in-house later?: You own the source, the infrastructure configuration and the documentation throughout. Handover is a planned step, not a renegotiation. Building it so a future developer can pick it up is part of the job, not a favour.
Do you only build things with AI in them?: No. AI is one tool among several and a bad fit for plenty of problems. A scheduling tool, a customer portal or a data import usually needs correctness and clear rules, not a language model. Where AI genuinely helps, I build it with the budgets, verification and escalation my independent projects demonstrate.