Home › Services › Applications
Built, hosted, and still running a year later
Two jobs, same team. A website that is actually maintained rather than launched and abandoned: built, hosted, patched and updated on a monthly retainer. And the small application that replaces a process currently running on a spreadsheet, a WhatsApp group and somebody’s memory, nominal upfront, then priced per transaction.
- Fee
- Two models + GST · websites: fixed build, then a retainer · applications: nominal upfront, then per transaction
- Websites
- Fixed build, then a retainer
- Applications
- Nominal, then per transaction
- Build
- 4–10 weeks, typically
Most website work is sold as a launch. The site goes live, the invoice is paid, and eighteen months later it is running an unpatched CMS, nobody has the login, the contact form has been quietly failing since a plugin update, and the only person who knew how it was built has left the agency.
We build it, host it, and keep it: patched, backed up, monitored, and edited when the business changes. A fixed price for the build, then a monthly retainer for keeping it alive. The domain, the DNS and the hosting account are yours and stay in your name, so the site is never held hostage to a relationship.
- Built. A site that loads fast on a phone on Indian mobile data, reads properly on a laptop, and says what the business does without three scroll screens of stock photography. Content you can edit yourself where you want that, and content we edit for you where you would rather not.
- Hosted. On infrastructure we run and monitor, with TLS, backups and a restore that has actually been tested. Not a shared box with a control panel and a promise.
- Maintained. Platform and dependency patching, uptime monitoring, form and enquiry delivery checked rather than assumed, and a monthly note saying what changed. This is the retainer, and it is the part that decides whether the site is an asset or a liability in year two.
We are not trying to sell you a system of record. The work that pays for itself at this size is narrower and much less glamorous: the approval that waits three days in an inbox, the field report typed twice, the dispatch note reconciled by hand at month-end, the customer who calls because there is no other way to find out where their order is.
Each of those is a small application. Built well, it removes a person-week a month and stops being interesting, which is the point. Built as a platform programme, it takes nine months, arrives after the process has changed, and gets used by nobody.
- Build. We map the process as it is performed rather than as the SOP describes it, then build the smallest thing that does the whole job: web, mobile, or a mobile front end onto a web back office. Source in your repository from the first commit.
- Host. Environments, deployment, TLS, backups and monitoring, in your cloud account if you have one and in ours if you do not. Either way the data is yours and the account can be handed over.
- Run. Support, fixes, dependency and security updates, and the small changes every real process needs in its first year. One number to call, and the engineers who built it.
The usual quote for this work asks for the whole build cost before anything runs, which puts the entire risk on you: you pay for a working system on the promise that it will be one. A per-transaction price inverts that. The upfront figure is nominal, and we earn the rest only as the thing is used.
A transaction is defined per application and written into the contract: an approval processed, a report filed, an order tracked, an invoice raised. It is never a page view or a login, because that would let us bill you for people opening the app and finding it unhelpful.
Three things we will put in writing, because this model can be abused and you should hold us to them. There is a cap, so a good year cannot produce an absurd invoice. There is a floor and an exit: a minimum monthly figure that keeps the service staffed, and a buy-out price to convert to a flat fee if the volume grows past the point where per-transaction makes sense.
And the counting is yours to audit: the transaction log is in your database, not ours.
Some of what gets asked for is already solved by something you own. If the answer is a form in the tool you already pay for, a rethought approval matrix, or three columns added to an existing report, we will say so. There is no version of this pricing model where we are paid for building it anyway.
We are also the wrong people for a consumer product with a growth roadmap, for anything that needs a design team on retainer, or for a core banking or ERP replacement. We build internal process applications, and we would rather be clear about the edge of that than take the work and learn on your money.
Boring, current, widely-known technology, hosted on a major cloud, chosen so that any competent development team in India can pick it up if you ever want to bring it in-house. No framework nobody has heard of, and nothing that only works because we are the ones running it.
Where the application touches your network, identity or cloud accounts, it is built to the same controls as the rest of what we do: authentication against your directory rather than a separate password list, and logs that go somewhere the security work can see.
What you walk away with
Yours to keep, and to hand to anyone else, including a provider that isn't us.
Talk to us about thisWeb, mobile or both, doing the actual job, not a pilot that needs a second phase to be useful.
Yours from the first commit. If you take it elsewhere, it goes with you.
Environment, deployment, backups, monitoring and updates handled, not handed back as a to-do list.
What it does, what it assumes and where it stops, because that is the half nobody documents.
Asked before you ask
The ones that come up on nearly every first call.
Talk to us about thisIs this a website, or an application?
Both, and they are priced differently because they are different things. A website is a fixed build and a monthly retainer for hosting and maintenance. An application that takes over a business process is nominal upfront and then priced per transaction, so what you pay follows what you use. If you are not sure which one you need, describe the problem and we will tell you. They are often not the same answer as the one you arrived with.
What counts as a transaction?
Whatever the application exists to process, defined per application and written into the contract: an approval completed, a report filed, an order tracked, an invoice raised. Never a login or a page view. If the definition is not obvious for your process, that is a conversation before the contract rather than a dispute after it.
What if volumes are much higher than expected?
There is a cap in the contract, so a good year cannot produce an absurd invoice, and a buy-out price that converts the arrangement to a flat monthly fee. We would rather agree both up front than renegotiate with you at the point where you have no leverage.
Who owns the code and the data?
You do, both, from the first commit. The source sits in your repository and the data in a database you can take a dump of at any time. Hosting it in our cloud account is a convenience, not a hold: we will migrate it to yours on request.
Can you take over an application somebody else built?
Sometimes. We will read the code and tell you honestly whether it is maintainable or whether you are better off rebuilding, and if it is the second, we will say what it would cost to do neither and keep limping along, because that is occasionally the right answer for a year.
Do we need to be on cloud already?
No. If you are not, we host it and the application is often the least disruptive first thing to run there. It does not commit you to moving anything else.
Not sure this is the one you need?
Tell us the symptom, not the service, and we'll say which of these applies, or that none of them do. A reply within one working day, from someone technical.
The rest of what we do
Most engagements start with one of these and grow into another.