How to plan an application before development begins

Planning an application is not a 40-page specification. It is a short set of decisions that the team can disagree with in daylight.

Start with the user and the job. “An app for everyone who wants to be more productive” is not a user. “A committee treasurer who records collections on Sunday evening” is. If you cannot name one person and one weekly moment, you do not have a first version yet.

Then cut the first release until it can fail cheaply. A first version that includes payments, referrals, a vendor marketplace, and AI chat is not ambitious — it is untestable. Ship the spine: account, the core record or capture, and one output (a report, a share, a listing).

Write the non-goals in the same document as the goals. Non-goals protect the build from polite additions that arrive mid-sprint. If iOS is not in version one, say so. If there will be no chat, say so.

Finally, decide how you will know it worked. “Users will love it” is not a measure. “Ten treasurers complete a month of entries without a support call” is. That sentence also tells you what to test.

At Weps Technologies we use a simple sequence on client and product work: discovery, design, development, testing, launch, support. Skipping discovery does not save time. It moves the confusion into engineering, where it costs more.

If you want a working session on this before you hire anyone — including us — bring: the user, the job, the first-version cut, and the non-goals. That is enough to have an honest conversation about scope.