Web apps and internal tools for businesses

Internal tools, client portals and dashboards built around a real workflow, with sign-in and roles, on your own accounts and at a fixed price.

A web app is the next step when a website is no longer enough: customers need to sign in and see their own information, or colleagues need to stop moving the same information between email and spreadsheets. What I build should be quick to use and dull to maintain.

Who it is for

Typical examples are a client portal where customers follow their order or upload files, an internal tool that replaces a spreadsheet, or a dashboard that shows the numbers without anyone compiling them by hand. A web app fits when the work already exists but is done by hand. Some signs:

• You send the same information back and forth by email because the customer cannot see it themselves.
• Someone enters the same information into two systems every week.
• You need to show different things to different customers, signed in.
• A spreadsheet has become business-critical, and several people edit it at once.
• You turn customers down because the workflow does not scale, not because there is no work.

One or two of the signs usually mean an existing service is enough, and then that is what you should use. Four or five mean the work already exists and is being done by people instead of a tool. Where the line runs is in When is a website enough, and when do you need a web app?.

What is included

A web app is built as a product build:

• Discovery and architecture. What the app should do and for whom, and how to build it so it is simple to own.
• Sign-in and roles. Accounts, password reset and who gets to see what.
• Build, test and deploy. On your accounts and your infrastructure.
• Analytics and admin from day one. Someone on your side can correct, add and remove without calling a developer.
• Post-launch fixes. 30 days of fixes after launch are included.

A web app is not a project that gets finished, but something you will own. How cheap that ownership is depends on how simple the build is, not on the choice of technology. A simple build you own beats an advanced build you rent.

How it works

First a free call about what is slow or missing, and whether it is worth building at all. Then you get the scope and a fixed price in writing. A web application typically takes four to eight weeks, and you get a fixed scope and a date before anything starts. The way of working is the same as for everything else I build.

The price is driven by accounts and roles, data, flows with exceptions, integrations and admin, not by the number of screens. Why two quotes for the same app can differ a great deal is in What does it cost to build an app?.

Price

The product build has a from price, because the scope differs a great deal between apps. You get a fixed price in writing after the call, before anything is built.

Common questions

Who owns the code and the data?

You do. Everything is delivered into your repository with documentation, and it runs on your accounts and infrastructure. I work under an NDA by default when data is involved. What a handover should contain is in Who owns the code?.

Can the web app become an iPhone app later?

Yes. A common approach is to start with the web app, let it prove that the workflow works, and build the native app once there are users who need it. How that works is under iOS apps.

What do you need from us to quote?

What a user should be able to do, in one sentence. The three most common cases and the two most awkward ones. Which systems the app needs to talk to, and whether you have access to them. And one person who owns the product and can answer questions while it is built.

What if we want to change something midway?

A change to the scope means a new proposal and a new fixed price before it is built, agreed the same way the first one was.