The spreadsheet held it together right up until it didn’t
Portals, internal tools and the systems a team runs on a shared sheet with color codes and a rule nobody wrote down. We build the painful part first and put it in front of the people who do the work. Then we build the rest around what they actually do with it.
In short: A web app is usually the shortest distance between a process that hurts and something better. We build one slice of it, get it in front of real users early, and let what they do with it correct the plan. The version people use is never quite the version they described.
The process already exists. It lives in a spreadsheet.
Most of these projects start the same way. Somebody made a sheet. It worked. It grew. Now there are seven tabs, three of them frozen, and a column of colored cells where orange means something specific to exactly one person on the team. When a cell turns orange, she calls the client before Thursday. Nobody wrote that down. It is the most important rule in the whole system.
Finding those rules is the first real work. Not the wireframes, not the stack. We sit with the people running the process and watch them do it, because the gap between how a process is described in a meeting and how it is performed on a Tuesday afternoon is where projects quietly fail. The exceptions are the point. Any tool can handle the clean case.
The unwritten rule
The condition that changes what happens next, known by one or two people and recorded nowhere. We write it down before we write any code.
The workaround
The second sheet somebody keeps privately because the shared one does not fit their job. It usually describes a missing feature exactly.
The repair job
Someone spends an hour each week fixing what other people typed. That hour is a validation rule waiting to be built.
The dead column
A field everyone fills in and nobody reads. Worth finding early, because rebuilding it in software makes it permanent.
One working slice, in front of real users, early
We would rather ship one process end to end than six processes halfway. A slice means a real user can do a real job with it and get a real result out the other side, even if four other things they need are still missing. That version is deliberately narrow. It is also the only reliable way to learn what the finished thing should be.
What comes back from that first release is rarely a feature request. It is more often a correction. The screen everyone argued about turns out to be used twice a month. A step described as trivial takes eleven clicks and is done forty times a day. Someone opens the app on a phone in a warehouse, which nobody mentioned. Plans built on interviews alone survive contact with users about as well as you would expect.
So we plan in slices and re-cost after each one. The spreadsheet stays alive alongside the app for the first few weeks, on purpose. Nobody should be stranded because the software does not yet handle the awkward case they meet on Friday.
The unglamorous parts that decide whether it lasts
Accounts and permissions come first, because internal tools grow sideways. The app you built for the operations team gets shown to a client, and now some records must be visible and others must not. Retrofitting that is painful. Building it in at the start costs very little.
Then the history. Who changed the price, when, and what it was before. Teams ask for this the first time a number is disputed, and by then the answer either exists or it does not. We also build the boring exits: export to a file, a way to correct a mistake, and error messages that say which field is wrong instead of blaming the user. Where the app has to survive load, deployment and monitoring belong in the plan from the start, which is where our cloud and DevOps work fits in. Testing is not a phase at the end either, and our QA team is involved while the first slice is still small enough to fix cheaply.
When a web app is the wrong answer
Sometimes the honest answer is that you already own the software and it just cannot talk to itself. In that case a set of integrations is cheaper, faster and leaves you less to maintain. Sometimes the work happens away from a desk, on a phone, offline, with a camera, and a mobile app is the better shape. And sometimes a configured off-the-shelf product covers ninety percent of what you need for a fraction of the cost, in which case we will say so before you have spent anything with us.
What we won’t do
We won’t build the whole thing before anyone uses part of it
A nine-month build with one reveal at the end is how teams end up with software that matches the meeting notes and not the work. If you need every module finished before launch day, we are probably not the right fit.
We won’t copy a broken process into software
If a step exists because of a rule that no longer applies, or an approval that nobody reads, we will push to remove it rather than encode it. Automating waste makes it permanent and harder to question later.
We won’t quote a fixed price for a vague scope
A number attached to an unclear brief is a guess with a signature on it. We would rather scope one slice tightly, price that honestly, and re-cost the rest once there is something real to look at.
Which part of the week costs you the most time?
Tell us about the process, not the software. We will tell you whether a web app is the right answer, and what the first slice of it should be.
The first usable slice normally lands in weeks rather than months, because it covers one process end to end instead of every process partly. Real users try it on real work. What they do with it then rewrites the plan for everything after it.
Can it replace our spreadsheet completely?
Usually, though not on day one. We keep the sheet running next to the app for the first weeks so nobody is blocked by a case the app does not handle yet, then retire it once the awkward cases are covered too.
Who owns the code and the accounts?
You do. The repository, the hosting and the deployment setup are in your name, and we document them well enough that another team could take the work over without calling us first.
We already have software that almost does this. Now what?
Then we would rather connect it than replace it. Building the missing piece between two systems you already pay for is often cheaper and leaves far less for your team to maintain afterwards.
