Software delivery and business systems

Business systems, websites, and the infrastructure under them

Six services, grouped by who ends up using the result rather than by what technology sits inside. You do not have to know which one you need. That is the seventh thing on this page, and it is the one most people start with.

One partner, the whole chain

StageWho owns it
Understanding the problemMe
Designing the systemMe
Building itMe
Deploying and securing itMe
Running it afterwardsMe

The usual arrangement splits these across three suppliers, and the seams between them are where projects are lost.

What you are actually buying

Building it is one stage out of five

Most quotes cover the building and go quiet about the rest. Then the system is finished, and it turns out nobody agreed who deploys it, who holds the accounts, who patches the server, and who answers when it stops at four on a Friday. Every service on this page is priced and delivered with all five stages in it. What is not on the page is day to day IT support: I build systems and keep them running, I do not staff a helpdesk.

  • One person accountable from the first conversation to the system running in production
  • Accounts, domains and certificates in your name from day one, not in mine
  • The source code is yours, complete and buildable, whatever happens between us
  • No margin resold on top of somebody else's hosting
  • You talk to me, not to an account manager who passes the message on

Where projects are usually lost

Split across suppliers

Agency builds it

Host runs it

Nobody owns the seam

You become the messenger

Here

One scope

One person

One number to call

One version of what is true

Infrastructure, hosting and security

What keeps it all running

The part with no interface. Nobody asks for it until the day it is missing, and that day is always inconvenient.

Before any of the above

Sometimes the answer is not a new system

Everything above assumes something should be built. Often it should not. You may already run several applications with nobody holding the picture of how they fit together. You may be looking at a supplier's quote you cannot judge, or at a project with capable people on it that still delivers nothing. In those cases the useful thing is a reading rather than a build. It is the one part of this site where I have no reason to sell you anything.

  • An architecture review of the systems you already run, and a map of them
  • The processes around them, and which steps exist only because the software could not do them
  • How changes reach production, and whether they can be undone
  • Someone to run a delivery that is not moving

Architecture and audits

Which one you need

Read itbefore deciding
Decidebuild, or not
Buildonly if it is right

The map and the findings are yours whichever way you decide, including the decision to work with somebody else entirely.

Still not sure which one you need?

Describe the problem in your own words. I will tell you which of these it is, or that it is none of them.