"I need a website" specifies an artifact, not a problem

A developer took a grocery store's request for "a website for my store", asked how the business actually operates, and built a retail sales and inventory system instead ^[1][3][7]. The useful part is not the pivot but the diagnosis: the request named an artifact and said nothing about the problem, and the gap between the two was worth weeks of build time ^[14].

The first assumption was e-commerce: product pages, cart, checkout, accounts, payments ^[2]. The workflow interview killed that. The store is physical, customers walk in, pick products, pay at the counter and leave, and there are no online orders, no delivery, no customer accounts and no online checkout ^[4][5]. An e-commerce platform would have been a correct implementation of a problem the business did not have. The actual pain was in the back office, where sales were tracked by hand, which made daily records, remaining stock, accurate profit and any trend over time hard to produce ^[6].

So the system records a sale and derives the rest: revenue and profit calculated, inventory updated, transaction saved ^[7]. The developer's worked example: a bottle at cost NGN 500 and selling price NGN 700, stock 100, customer buys three, giving revenue NGN 2,100, cost NGN 1,500, profit NGN 600, and remaining stock 97 ^[8]. That is NGN 200 of margin per unit, about 29 percent of the selling price ^[1][2]. Staff are not asked to work any of that out ^[8].

Two of the design decisions are the ones that separate a records system from a form with a database behind it.

First, the arithmetic lives on the server. The frontend posts only a product ID and a quantity; the backend confirms the product exists, checks stock, reads current prices from the database, computes total, cost and profit, updates inventory and writes the transaction ^[9]. According to the author, the point is that a client cannot edit a frontend value and change the recorded profit ^[10].

Second, each sale item stores a snapshot of product name, quantity, cost price, selling price, subtotal and profit, so an old transaction stays accurate after the product is edited ^[12]. The reason is concrete. If the same bottle later moves to NGN 600 cost and NGN 800 selling ^[11], recomputing that three-unit sale at current prices would report revenue of NGN 2,400 rather than NGN 2,100, an overstatement of NGN 300, while profit happens to stay at NGN 600 ^[3]. A reporting bug that leaves the profit line intact is exactly the kind that survives a review.

Stock rules get the same treatment. With five in stock and a recorded sale of seven, the server rejects the transaction with an available quantity rather than saving negative two; the frontend may warn, but enforcement is server-side ^[13].

The same failure mode shows up in a different market. A founder-services operator in Taiwan reports that founders routinely ask for a website before the underlying operating decisions are settled, which produces avoidable rework because domain, contact details, invoicing flow, legal pages, content ownership and site architecture all depend on decisions outside the codebase ^[15][16]. Their scoping question is what evidence the site must produce: qualified leads, bookings, pre-orders, signups, distributor inquiries or completed purchases, and that answer should drive scope more than a feature list ^[17].

Worth watching: whether the store's numbers are trusted enough to act on, and whether asset control is written down. The Taiwan account is blunt that a site can look finished and still be a liability if nobody knows who holds the domain or the production credentials ^[19].