Your first version should do one job properly. Cut everything else.

One job, all the way through

Here's a composite example. An accounting firm wants a client portal. The list on the first call has twenty-two items: document upload, a checklist of what's missing, e-signatures, invoicing, payments, a messaging inbox, appointment booking, a dashboard for partners, three kinds of staff role, custom branding per office, a mobile app, integration with the tax software, and more.

Every item is reasonable. Together they're a year of work and a budget the firm doesn't have. More to the point, nobody knows yet which of them clients will actually use.

So we'd start by asking a different question: what is the one job that, if clients could do it well through the portal, would make the firm's life noticeably better this tax season? For this firm it's clear. Clients send their documents, and both sides can see what's still missing. That's the job. The first version should do that job properly, from the client's first login to the accountant marking the file complete, and do very little else.

Then we go through the list with a pair of scissors.

Cut: admin you can replace with a person

The first things to go are screens for your own team. Settings pages, user management, content editing, reports. They feel essential because your team will live with the software, but in the first months a person can often do the job by hand.

New client accounts can be set up by a staff member instead of a self-service sign-up. The checklist of required documents can be set per client by an accountant in a simple form, not a configurable template system. Reminders can be sent by a person looking at a list each Monday.

Anything you can do by hand for the first three months is a candidate for the cut. That's a rule of thumb, not a law, and it comes with a condition: write down what's being done by hand, by whom, and how often. That list is your evidence for what to build next. Our note on the spreadsheet that's already your software is a reminder that manual doesn't have to mean messy.

Cut: settings, roles and "what if a customer wants..."

Next go the features that exist for edge cases. Custom branding for each office. Five permission levels where two would do. A setting for clients who want reminders by text instead of email. "What if a client wants to upload on behalf of their spouse?"

Each of these adds screens, testing and things that can go wrong. Most can wait until a real user asks for them, which also tells you how many users actually want them. Keep a list. When the same request shows up from several people, it moves up.

Polish goes the same way, selectively. Spend design time on the screens clients see every time they log in: the upload, the checklist of what's missing, the confirmation that something arrived. Pages people visit once a year, like account settings or the help page, can be plain and clear for now. Plain isn't the same as broken. They still need to work and make sense, they just don't need the care that goes into the screen a client opens every week in March.

The exception is anything that affects who can see what. If clients must never see each other's documents, that's not a setting. That's a foundation, and it stays.

Cut: dashboards and most integrations

Reporting dashboards are almost always the wrong thing to build first. You don't yet know which numbers matter, and the data to fill them doesn't exist until the portal has been used. A plain export to a spreadsheet covers most early questions.

Integrations deserve a harder look. Connecting to the tax software, the invoicing tool and the calendar sounds efficient, but each one is its own small project with its own failure cases. For a first version, ask whether an export, an import or a person copying a few fields is good enough for now. Sometimes the answer is no, because the integration is the job. Usually it's yes.

The mobile app goes too, for now. A portal that works well on a phone's browser covers document upload for most clients. Our note on whether you need an app or a good mobile website goes through that decision.

Keep: what's expensive to add later

Now the things we'd argue to keep, even when the budget is tight:

• The core job, end to end. Not most of it. All of it. A portal where clients can upload but accountants can't mark things received isn't a smaller version, it's a broken one.
• A data model you trust. How clients, documents, tax years and requests relate to each other is hard to change later. Get it right now, and make sure you can export everything.
• Sign-in and permissions done properly. Secure login, password reset that works, and clients seeing only their own files.
• Basic accessibility. Clear labels, keyboard use, readable contrast. It costs little at the start and a lot to retrofit.
• A way to see when something breaks. Error logging and an alert, so you hear about a failed upload before the client calls.

These are the parts that are cheap to do once and expensive to fix after people depend on the software.

Put one thing back

Once the list is cut, look at it again and ask: is there one thing that would make clients choose the portal over emailing attachments? For the accounting firm, it might be photo upload from the phone camera, with automatic cropping, because that's how clients actually have their receipts. If there's a single feature like that, put it back. Just the one.

Then ship it, watch how people use it, and plan version two from the manual-work list and the requests that kept coming up. That gives the next round of spending real evidence behind it. Pricing the work in phases fits this naturally. Our notes on writing the brief before you pick the builder and on fixed price versus time and materials go further into both.

We build web applications and mobile apps, and the scoping conversation is usually where we're most useful. If your first-version list is long and the budget isn't, bring the list and we'll cut it together.

Related work: Spin:Market.