Automation

Custom web application development for a process no product fits

The process runs on a workbook nobody dares touch any more. Three versions are in circulation, the formulas were written by someone who has since left, and everything the workbook cannot do happens by email. You have looked at what is on the market, and every product does something slightly different from what you actually do.

A custom web application is one application, built for one organisation, in your own vocabulary and your own steps. Not an existing product bent into shape, but software that follows the process as it runs in your organisation. That is not automatically the better option. It is the right one when the process itself is what distinguishes your organisation, or when no existing product covers the combination of data and steps you need. In every other case buying is cheaper, and I will say so.

When custom pays for itself

Custom costs more than a subscription, and it stays yours, maintenance included. It pays for itself in situations like these.

The process runs on a shared workbook with formulas nobody dares change, and on email for everything that workbook cannot do.
You have looked at existing products and kept getting the same answer: it almost fits, provided you change the way you work to suit the product.
What you do is precisely what sets you apart from your competitors. You are not willing to trade that for a supplier's standard configuration.
Several people work in the same data at once, and the errors that come out of it now cost more than an application would.
You need data from two or three systems on a single screen, and no such screen exists.
There is a requirement around access, approval or auditability that loose files cannot meet.

What the engagement covers

Building is the shortest part. Most of the work sits before it and after it.

Writing down the process as it genuinely runs, including the exceptions that live only in someone's head.
Agreeing what version one does and does not do, and recording it before a line of code is written.
Design of the data model, screens and permissions: who sees what, who changes what, and what happens when two people edit at the same moment.
Integrations with what is already running, via API or file exchange, so data is maintained in one place rather than three.
Building in mainstream, widely supported technology, so the next developer can take it over without first learning something rare.
Migration of what sits in the existing files, including the clean-up that surfaces along the way.
Hosting, backups, a restore procedure and a test environment, so a change does not land straight in production.

What you are left with

A working application, and everything needed to carry on without me. The second part is not an added service; it is the definition of finished.

The application, running on hosting registered to your organisation. Not on my account, not inside my subscription.
The complete source code with its history, in a repository that belongs to you. Intellectual property transfers to your organisation on delivery and full payment; that is agreed in writing beforehand.
A technical handover: how it is built, why those choices were made, how you deploy, where keys and settings live and how you grant someone else access.
A short set of instructions for the people using it daily, and a separate one for whoever maintains it.
A list of what was deliberately left out of version one, so the next step is a decision rather than a discovery.

What it is not

Not a replacement for software you can simply buy. If you do what many other organisations do, an existing product is cheaper and better maintained, and that is what I will advise.
Not an arrangement that ties you to me. Hosting, code and knowledge do not stay on my side.
Not a system that takes over your whole operation. One process built properly, with integrations to whatever else runs.
Not a prototype that ends up in production by accident. What is delivered is built to be operated, with backups, logging and a way to recover it.
Not an open-ended project. If a first version is heading towards a year of building, the scope was chosen wrongly, not the technology.

Common questions

When is custom the wrong answer?

When the process is not distinctive. Bookkeeping, payroll, a webshop, a booking calendar: products exist for these, maintained by whole teams, and you can use them for a fraction of what building costs. Custom pays off when the process itself is the differentiator, or when no product covers the combination of data and steps you need. The honest order is: first check whether it exists, then build. That conversation is available on its own, with no obligation to have anything built.

Who owns the code?

You do, provided that is agreed up front. By default copyright rests with the maker, so for a build engagement I record explicitly that intellectual property transfers to your organisation on delivery and full payment. More practical still: the repository sits in an account owned by your organisation from day one, not in mine. What I keep is generic knowledge and experience, not your application.

What happens if you stop, or get hit by a bus?

A fair question to ask of a one-person practice, and the answer should not be 'that will not happen'. The answer is that the engagement is set up so my disappearance is an inconvenience rather than a disaster: your own hosting accounts, your own repository, mainstream technology instead of something rare, and documentation written for a developer who has never spoken to me. The test I hold it to is simple: can a competent developer get this running on a clean machine within a day, using only what is in the repository? If not, it is not finished.

Where does it run, and who maintains it?

On hosting registered to your organisation, with a provider you can cancel without calling me. For an application of this size I choose a managed environment with backups and security updates included, which saves you a server administrator. Maintenance afterwards can sit with your own IT partner, with me in an agreed form, or with nobody for a while: a finished application is allowed to run untouched. What does need doing is set out in the handover.

What belongs in the first version?

The path that gets walked most often, start to finish, for the people who walk it daily. Nothing more. What does not belong: exceptions that occur twice a year, reports nobody has asked for yet, a permissions structure for roles the organisation does not have, and configurability for wishes that do not yet exist. Each of those adds build time and is better designed once real use is visible. A first version that goes live quickly teaches you more than a complete one delivered a year later.

What drives the price?

The number of screens and steps, the number of integrations with existing systems, the state of the data that has to come across, and the requirements around access and auditability. Integrations and data migration carry the most uncertainty, so I cost them separately. The shape is agreed beforehand: a short engagement of a few days to write up the process and cost the build, then time and materials against an agreed ceiling, or a fixed price for a defined result once the scope is sharp. I name a rate in the first conversation.

More within this service

A process that calls for its own application?

An introductory conversation is without obligation. Sketch what currently runs on spreadsheets and email; I will say honestly whether custom is the right call here, or whether something off the shelf would serve you better.

Book an intro call Send a message