Hire a software developerHire — Software Development
For the software a business runs on rather than the software it sells: internal tools, integrations between systems that were never meant to talk, and the processes currently held together by a spreadsheet and one person who knows the trick.
The software businesses actually hire developers to build
Very little commissioned software is a product. Most of it is the connective work that keeps an operation running, and it is usually invisible until it breaks.
- Internal tools that replace a spreadsheet several people edit at once
- Integrations between systems bought years apart that do not speak
- Customer or partner portals sitting on top of an existing database
- Automation for a process currently done by hand every week
- Reporting that answers a question the off-the-shelf dashboard cannot
- Migrations off a platform that has stopped fitting the business
Scoping work when nobody has written the requirements down
Most of this work starts without a specification, because the process being replaced lives in people's heads rather than in a document.
So scoping starts by watching what actually happens — including the exceptions everyone handles automatically and nobody mentions. Those exceptions are where custom software either earns its cost or quietly fails to get adopted. The written scope that comes out of it names what is excluded as clearly as what is included.
Buy, configure, or build
The honest first question is whether this needs building at all. Something off the shelf usually exists, and when it fits it wins on cost, support and the fact that somebody else maintains it.
Building earns its place when the process is genuinely specific to how you operate, when the integration surface is the hard part, or when per-seat licensing on a growing team has stopped making sense. I would rather tell you the tool already exists than take a build a subscription would have solved.
Why businesses hire software developers directly
Going direct removes the account manager, the discovery phase billed before anything is built, and the handover between the person who scoped the work and the person who writes it.
What you take on instead is concentration risk — one person holding the knowledge. That is why the repository, hosting accounts and documentation are yours from day one rather than at the end. It is what makes the risk survivable, and it is not negotiable on my side.
Working with the systems you already run
Almost none of this is greenfield. New work sits alongside an existing database, authentication model and deployment process, and has to respect all three rather than start a parallel stack nobody owns.
Where an old system has no API, the integration is built against whatever it does expose — a database, a file drop, a scheduled export — and documented so the next person knows why it works that way.
Custom systems that shipped
Business software built for clients — platforms, portals and internal tooling. Each links to how it was built.
Common questions
What does it cost to hire a software developer?
- The number follows the scope, not the other way round. What moves it most: how many distinct kinds of user the system has, how many existing systems it must integrate with, whether data has to be migrated from something live, and whether the process being automated is well understood or still being figured out. Any figure quoted before a written scope exists is a guess, and the padding for that guess is in the price.
Do we need a full specification before you can quote?
- No — producing one is usually part of the work. What is needed to start is the problem, who does the job today, and what happens when it goes wrong. The written scope comes out of that conversation, and it is what the quote is built against.
Can you work with the software we already have?
- Yes, and most engagements do. New work runs against your existing database, authentication and deployment rather than beside them. Where a legacy system has no API, the integration is built against whatever it does expose and documented so the reasoning survives the handover.
What happens to the code and accounts when the work is done?
- They were never mine. The repository, hosting and third-party services are created in your name at the start, and documentation is written as work lands rather than compiled at the end — written for a developer who has never seen the project, because eventually one of them will.
Trusted by teams at












Have a role, a project, or a hard problem? Wherever you're based, I read every message and reply within a couple of days.