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. Where the application runs and who owns the code is agreed up front.

The application, hosted as you choose: registered to your organisation, or with me as a managed service covering hosting, backups and maintenance for a fixed price. Either way you can export all your data at any time.
The source code with its history. If you want to own the intellectual property yourself, I transfer it to your organisation in writing on delivery and full payment, with the repository in your name. Otherwise you receive a right of use for an indefinite period. Which form applies 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 you cannot walk away from. Even when I host and maintain it, you get a full export and a handover note, so someone else can take over.
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?

That is agreed up front, and there are two forms. By default copyright rests with the maker; it can only be transferred in writing. If you want to own the code, I record that intellectual property transfers to your organisation on delivery and full payment, and the repository sits in an account owned by your organisation from day one. If you take the application as a managed service from me, the intellectual property stays with me and you receive a right of use for an indefinite period. Either way your data is yours and you can export it at any time.

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?

You choose up front. On hosting registered to your organisation, with a provider you can cancel without calling me; 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. Or with me as a managed service: I host the application in a managed environment, with backups, security updates and maintenance for a fixed price, cancellable at an agreed notice period. What needs doing in either case 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. Hourly rate €125 excl. VAT.

In practice

GMS Forms for Global Maritime Survey

An inspection platform where auditors fill in and sign on board, even offline, and where the office reviews and sends the report to the shipping company.

See the GMS Forms reference

Website with a stock feed for De Kok Export

A site whose stock keeps itself in step with the dealer's Autoline page every hour, photos and sold status included, with a nightly backup and an alert if it fails to arrive.

See the De Kok Export reference

CustomerGate 365 for Business Central

My own app that connects a company's website to Business Central: quote requests, portal accounts and a customer portal with quotes, orders, shipments and documents.

See the CustomerGate 365 reference

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 introductory call Send a message