Software development for the parts of your business nothing off-the-shelf fits

Which kind of build do you need?

Web applications cover internal tools and customer facing systems used through a browser, which is most business software and the right default. SaaS development applies when you are building a product to sell to others, which brings multi tenancy, subscription billing and support obligations that an internal tool never has. API development is for connecting systems or exposing your own data to partners. Cloud applications describes architecture built for elastic scale rather than a fixed server.

On mobile, the first question is whether you need an app at all. A responsive site or a progressive web app covers a lot of ground without app store review cycles. When you genuinely need native capability, camera, background location, offline field use or push at scale, then iOS and Android builds make sense, and cross platform development often serves better than two native codebases. If what you actually need is a well understood pattern such as a CRM, booking system or portal, start in business systems instead, where the ground is already mapped.

What a software engagement looks like

We break the work into a defined first release and everything after it. The first release is the smallest version that a real user can do real work with, usually 8 to 16 weeks depending on complexity. Anything not required for that is written down and scheduled rather than built speculatively, because features nobody has used yet are the most expensive kind of guess.

Delivery runs in two week increments on an environment you can log into throughout, so priorities can change with evidence rather than at the end. Automated tests, continuous integration and deployment documentation are part of the build, not an optional extra, because they are what makes the second year affordable. Everything sits in a repository under your organisation from day one, with infrastructure in accounts you control.

• A first release a real user can work in, not a demo
• Two week increments on an environment you can open at any time
• Automated tests and continuous integration from the first sprint
• Architecture decisions recorded in writing with the reasoning
• Repository, cloud accounts and credentials in your business name

The expensive mistake: building what you could configure

Custom software costs more than a subscription and always will. It is worth it when the process is a genuine advantage or when the available products force a compromise that costs more than the build. It is not worth it when the honest reason is that the team dislikes the interface of a product that would otherwise do the job. We will say so, and we would rather lose that project than deliver something you regret paying to maintain.

The second mistake is scope written as a wish list. A specification with two hundred requirements gathered from every department produces a build that arrives late, costs double and delivers a system where the twenty features people needed are buried under a hundred and eighty they do not use. We insist on a first release defined by what one user needs to complete one job end-to-end. Everything else waits for evidence. The third mistake, and the quietest, is ignoring the running cost: hosting, monitoring, dependency updates and support are real annual obligations, and we put them in the proposal rather than leaving you to discover them.