Web apps and internal tools when a spreadsheet is no longer enough

Who this is for

You are a fit when a spreadsheet, a shared inbox, or a chain of forms is dropping information, and the people involved are on your team or are logged-in customers. Examples we will consider: a client portal that shows project status, an intake form with branching questions, a simple inventory list for one warehouse, a staff roster that is not a full HR suite. You are not a fit if you need a multi-sided marketplace, a custom payment processor, or a social network. Those are larger products than this service.

If the job is a public marketing site, stop here and use web design. The website price ladder on pricing ($99 to $300 by page count) is for that public site. An application is quoted from the screens and the rules, because a login and a database are not "one more page".

What a version one includes

The smallest release that replaces the broken step. We write the roles: who can see what. We list the fields and which ones are required. We name where the data lives and that the account is yours. We design the empty state so the first day is not a blank error. We include a way to export the data, because you should be able to leave with your records.

Authentication uses a normal method we name in the quote. We do not store passwords in a spreadsheet. Admin actions that delete data ask for a confirmation. We log the actions that matter if the scope says so, and we skip a fake "audit trail" graphic that records nothing.

A public page can link to the tool. The marketing site and the app stay separate deploys when that keeps the marketing site simple. Performance habits for the public site are described in Next.js Core Web Vitals on the Vercel free tier. The app gets the same measurement idea: the screen you use every morning should load without a spinner that never ends.

How we scope and ship

1. Watch the current workaround. A screen recording of the spreadsheet is more useful than a feature list copied from a large product.
2. Cut version one to the step that fails today. Later steps stay on a list, not in the first invoice.
3. Design the flow with UI/UX design if the path is branched, otherwise sketch it inside this project.
4. Build, then you enter real sample records on staging. We do not launch on invented demo customers presented as if they were yours.
5. Hand over the repository, the host account, and a short operating note. Care after launch is optional and looks like website maintenance adapted to an app: updates, small fixes, and a backup of the data.

If a CRM already does the job, we will say so and point you to CRM setup instead of building a clone.

Problems we push back on

A requirements document that is a tour of a famous app. Version one copies your workaround, not their marketing site. We will mark items as later.

Unowned data. If nobody can name where the records should live in a year, we do not start. The host and the database are in your name.

Hidden admin. A tool with no way for you to fix a wrong record will page us forever. We include a plain admin path for the fields you edit.

Fake precision. We will not add charts that imply forecasting magic. If the number is a count of this week's intakes, the screen says that.

Handover checklist

Before we call it done you can sign in as the owner, export a sample of records, and reset a staff user. The operating note names the host, the repository, and where logs live if we added them. If a step in that list fails, version one is not finished, even if the happy path looks polished in a demo.

Related reading

Teams replacing a public site at the same time should read how much a small business website costs so the brochure budget and the app budget are not mixed into one number. Security of the admin login belongs with the habits on security and backups.

Describe the spreadsheet and the step that breaks. Send it through contact. We will answer with a version one outline or with a reason to use a tool you can rent instead.