01Problem and objectives
Independent cafés, bakeries, salons and massage studios run their day on the phone, a paper diary and a printed allergen sheet. Lunch orders interrupt service, stylists miss booking calls during treatments, and customers with allergies cannot trust incomplete letter codes. Discovery with 14 businesses and 22 customers put numbers on it.
| Objective | KPI | Baseline | Target |
|---|---|---|---|
| OBJ-01 Cut uncollected pickup orders | Ready orders marked Not collected | 6.8% | 2.0% or less |
| OBJ-02 Cut appointment no-shows | No-show rate of app-booked appointments | 9.5% | 5.0% or less |
| OBJ-03 Take bookings when the phone cannot | Share of app appointments created outside the location's opening hours | 0% (phone only) | 30% or more |
| OBJ-04 Complete and current allergen information | (a) Orderable food items with a complete allergen declaration; (b) orders placed on outdated allergen information | (a) 58%; (b) not measured | (a) 100%; (b) 0 |
| OBJ-05 Onboard businesses quickly | Median business days from application to Live | 11 | 5 or fewer |
| OBJ-06 Free counter staff at lunch | Staff minutes on phone orders per lunch service (11:30 to 13:30) | 38 | 15 or fewer |
The hard parts are where money, capacity and safety meet: a basket mixing 10% and 20% VAT with a voucher, a pickup slot that fills while a bank challenge is still running, and an allergen declaration that must never be stale when someone orders.
02My role and approach
I ran the full lifecycle as the sole BA and wrote every artifact to the standard a delivery team would review it against. Each phase lists the documents it produced; click one to open it.
Discover
Interviews with 14 businesses and 22 customers, a survey of 410 residents, measured baselines, personas, AS-IS and TO-BE flows and a market scan.
Define
A BRD with six objectives and an explicit out-of-scope list, a 29148 SRS with 76 FRs, 45 rules in decision tables, 27 NFRs and a compliance mapping.
Design
C4 architecture, three ADRs, ERD and data dictionary, sequence diagrams, state machines, five wireframes and a 42-operation OpenAPI contract.
Build
Seven two-week sprints for R1: 38 stories in 6 epics with 166 Gherkin criteria, change control and a weekly rule clinic.
Test and UAT
A risk-based test strategy with 98 test cases, the worked examples as boundary tests, and 10 UAT scripts signed off with pilot businesses.
Launch and operate
A pilot with 38 businesses, then the city launch; two blameless reviews produced CR-005 and CR-006 for release 1.1.
03Inside the documents
Open any document below. It renders here from the repository, with the diagrams drawn live. The two anchor documents are also available as formatted PDFs.
04Designs
Five annotated wireframes in German, as the product ships: the menu with an allergen filter, checkout and order status, salon start times, the staff POS order board and the item editor where allergens are declared. Click any screen to enlarge it.
05Key decisions
These are the calls I would expect to defend in a design review.
Allergens are a publishing gate, not a disclaimer
No food item can be ordered without a complete, confirmed declaration of the 14 EU allergens, and every change creates a new version (BR-011, BR-013). Discovery had suggested showing "information not available, ask the business" instead.
The POS view is an order board, not a cash register
Taking counter payments would have brought the platform under Austrian cash register rules while every pilot business already had a certified register, so CR-003 was rejected and staff only confirm payment at the counter.
Authorize at placement, capture at acceptance
The card is authorized when the customer orders and captured only when the business accepts, so a rejected or timed-out order costs nobody anything (ADR-003).
A hold is a courtesy; the database decides
Slot holds live in Redis with a time-to-live, but capacity is enforced by the database and re-checked when payment is authorized, with alternative slots offered if the slot filled up (ADR-002, CR-006).
06Traceability explorer
Pick an objective, then a requirement, to follow its chain through business rules, stories, API operations and tests. The data comes from the generated traceability matrix in the repository.
07Worked example
One calculation runs through the whole document set with identical numbers: the SRS, the business rules, a story's acceptance criteria, the test cases and the test data.
For salons: with a 09:00 to 13:00 shift, an existing 10:30 to 11:15 appointment and a 45-minute cut plus a 15-minute buffer, the app offers 7 start times and excludes 12:15 because of the buffer.
08Incidents to requirements
Production incidents are where requirements prove themselves. Each review is blameless, with a timeline, 5 Whys and corrective actions, and it closes the loop with a change request.
| Incident | What happened | Requirement change |
|---|---|---|
| SEV-1 Stale allergen information INC-2026-006 | A 24-hour CDN cache served an outdated allergen declaration for almost five hours after a bakery added hazelnut to a cake; 11 orders from 9 customers were affected, and no reaction was reported. | CR-005: allergen declaration versions, freshness checks and re-confirmation at checkout |
| SEV-2 Pickup slots over capacity INC-2026-011 | One card issuer's slow 3-D Secure outlasted the 10-minute slot holds, and orders were created without re-checking capacity: 23 orders landed in full slots and 6 customers were refunded. | CR-006: slot capacity re-checked at payment authorization, and holds extended during 3-D Secure |
09Tech stack
The stack documented in the architecture. As the BA I own the requirements it must satisfy, the integration contracts and the quality scenarios, not the code.
- Customer app
- Flutter (Dart), one code base for iOS and Android
- Web portals
- React with TypeScript (Vite), shared WCAG 2.2 AA components
- API and workers
- Node.js with NestJS as a modular monolith
- Realtime
- Socket.IO over WebSocket with a Redis adapter
- Database
- PostgreSQL 16 with PostGIS and pg_trgm
- Holds and queue
- Redis: time-to-live slot holds, jobs for timeouts and reminders
- Notifications
- Firebase Cloud Messaging (APNs for iOS)
- Payments
- Card payment provider with SCA, 3-D Secure 2, wallets and connected accounts
10Reflection
What worked. Writing the money and capacity rules as decision tables before any screen was drawn. The two worked examples became boundary tests, and the incident reviews could point at the exact rule that needed to change.
What I'd do next. Validate the salon flow with more stylists before Release 2, measure the onboarding target with a larger cohort, and add classes and events for spas, which were deliberately moved out of Release 1.