Web application development
Building the thing that runs your business process: an internal tool, a customer portal, a booking or scheduling system, a reporting dashboard. Delivered as working software plus the things that make it maintainable — a README that lets a new developer run it locally, automated tests around the parts that matter, and deployment that is a command rather than a ritual.
The decision worth making early is build versus buy. A large share of custom software requests are better solved by configuring an existing product, and a developer who tells you that up front is saving you a recurring maintenance liability rather than losing a sale.
APIs and integrations
Connecting systems that were not designed to talk to each other: a CRM to an accounting package, a storefront to a fulfilment provider, a legacy database to something built this decade.
Integration work is mostly about failure. The happy path is quick; what takes the time is deciding what happens when the other system is down, returns something unexpected, or silently changes its contract. Ask any prospective developer how they handle retries, idempotency and partial failure — the answer tells you a great deal.
Bringing an existing codebase back under control
Inherited software with no documentation, no tests, and an original author long gone. The sequence that works is: get it running reproducibly, get it under version control if it somehow is not, write tests around current behaviour before changing anything, then change things.
Rewriting from scratch is almost always the more expensive option and is chosen far more often than it should be. The existing system encodes years of business rules nobody has written down, and a rewrite rediscovers them one production incident at a time.
Performance and cost work
Applications that have become slow, or cloud bills that have grown faster than usage. Both start with measurement rather than intuition. Most serious slowness in business applications resolves to database queries — missing indexes, or code issuing one query per row in a loop. Most surprising cloud bills resolve to something provisioned for a load test two years ago and never turned off.
Technical due diligence
An independent read of a codebase before you acquire it, invest in it, or take it over. What it is built on, how much of it is maintained, what the licensing exposure is, where the security problems are, and what it would realistically cost to keep running.
Which do you need
| Situation | Engagement |
|---|---|
| A manual process eating staff time | Web application — after a build-versus-buy check |
| Staff retyping data between systems | Integration |
| Software works, nobody dares change it | Stabilise: tests and documentation first |
| It was fine, now it is slow | Performance work, starting with measurement |
| About to buy a company for its software | Due diligence |