The Blog

Twelve products in roughly a year is an unusual output for a single-person build, and the number invites a question I get asked often: what was actually driving the pace. These are MVP-stage personal hobby projects, not production deployments — the value of the exercise was the discipline behind building them, not the claim that they're commercially shipped. The honest answer has little to do with working faster and much more to do with removing decisions that didn't need to be made twelve separate times. FinanceFlow, ClinicFlow HMS, CargoFlow, TransportFlow, GuestFlow, MuscleFlow, FactoryFlow, RestoFlow, ProjectFlow, HRFlow, EduFlow, and RetailFlow now make up the portfolio, each addressing a distinct small-business workflow, and each built on a common substrate that made the marginal product cheaper to build than the one before it.

A fixed methodology across variable products

Every Flow product follows the same underlying discipline regardless of its market: a DPDP-compliant data model established before schema design begins, an agent-ready backend so AI capability is architected in rather than retrofitted, and a written BRD/FRD pair that precedes interface work. The visual and functional identity of each product diverges completely; CargoFlow's logistics workflow shares almost nothing on the surface with EduFlow's course-scheduling calendar, but the requirements discipline underneath does not vary. That fixed layer is what made repeatable throughput possible, since each new product reused a decision framework rather than requiring one to be invented from scratch.

What the first three products got wrong

ClinicFlow, CargoFlow, and FinanceFlow, the first three builds, consumed a disproportionate share of total build time relative to everything that followed. The cause was straightforward: requirements and implementation were happening concurrently, which meant any feature added mid-build bypassed the BRD entirely and left no record of what had been decided or why. Beginning with the fourth product, that sequencing changed. No feature enters a build without a corresponding BRD line item, regardless of whether anyone besides the author will ever read it. That single procedural change reduced build time on the subsequent products by roughly a third, a reduction attributable almost entirely to fewer late-stage reversals rather than faster initial drafting.

UAT discipline followed a similar correction. Early products were tested during construction, which produces the appearance of efficiency while deferring the actual cost of defect discovery to a point where fixes are more expensive. From HRFlow onward, every product undergoes a dedicated UAT pass against the BRD's acceptance criteria before release, mirroring the governance model already in place on the enterprise loyalty platform program at a global consulting firm, applied here without a contractual mandate.

What comes next

RealtyFlow, covering listings, showings, and lease tracking for small brokerages, is the newest addition to the portfolio, alongside an early-stage workshop and service-centre console for automotive and mechanical shops. In parallel, a shared account layer is in early planning so that a business running two or three Flow products, RetailFlow and HRFlow together, for instance, can operate from a single login rather than maintaining separate credentials per product.

I'm also open to external engagement built on what these hobby projects taught me: white-labeling an existing Flow build for your business, a commissioned build for a niche this portfolio doesn't cover yet, or a BSA-led audit of your existing systems. Inquiries can be routed through the contact section.

On the AI Innovation and Integration team at a global consulting firm, the recurring question is whether to fine-tune a model on internal documentation or to build a retrieval layer on top of a general-purpose model. After building and running several n8n workflows using the latter approach across a business analysis workload, the conclusion is fairly unambiguous for this domain: retrieval-augmented generation outperforms fine-tuning on the dimensions that matter most to a BSA function, and fine-tuning solves a problem that this particular workload rarely has.

The case against fine-tuning here

Business requirements change on a rolling basis, often weekly within an active delivery program. A fine-tuned model encodes the state of the process at training time, and by the point enough new examples have accumulated to justify a retrain, a meaningful share of them describe a workflow the organization has already moved past. A retrieval-based system avoids this problem structurally: the underlying model stays general, and domain knowledge lives in a vector store that can be updated the moment a process changes, without touching model weights at all. On a program spanning five delivery segments and over a hundred people, that update velocity outweighs whatever marginal quality gain fine-tuning might offer on a static task.

The workflow structure

The n8n pipeline runs in four stages. Approved BRDs, FRDs, and UAT logs are chunked and embedded on save, tagged by delivery segment and document type, forming the ingestion layer. When a BSA begins drafting a new requirement, the system retrieves the three to five most similar historical requirements along with any linked defect history. Those retrieved chunks are passed to the model with a narrowly scoped prompt requesting a first-draft requirement in the team's standard format, explicitly framed as a draft rather than a finished artifact. Every output is then routed back to a human BSA for review before it touches a real BRD, a step that is treated as non-negotiable and is, in practice, the reason the rest of the team trusts the system at all.

Where the time savings actually appeared

The workflow did not meaningfully accelerate the drafting of genuinely novel requirements; the model is only as useful as what exists in the vector store, so unprecedented requirements still begin from a blank page regardless of tooling. The measurable savings clustered in the repetitive portion of the work: acceptance criteria phrasing, cross-referencing related requirements from prior releases, and flagging contradictions between a new requirement and an existing one. These are retrieval problems by nature, and a well-built retrieval system is suited to them in a way that generation alone is not.

Where fine-tuning would still make sense

A genuinely unusual documentation style, a rigid, heavily regulated legal format that a base model consistently mishandles even with strong context, is a scenario where fine-tuning can close a residual gap that retrieval cannot. That was not the situation here. For most BSA teams sitting on several years of BRDs and FRDs, a properly constructed retrieval pipeline captures the large majority of the achievable value at a fraction of the engineering and maintenance cost of fine-tuning. Teams weighing the same decision are welcome to compare notes through the contact section.

The Amazon Q pilot on the enterprise loyalty platform program was scoped around a single measurable question: does generative AI reduce BRD drafting time in practice, or does it simply relocate the effort from writing to editing. After a full quarter of production use across five delivery segments, the data supports a genuine 25% reduction in drafting time, but only once usage moved away from the pattern most product demonstrations imply.

The approach that underperformed

Prompting Q to draft a complete BRD from a single-line description produces output that has the surface texture of a requirement without the underlying structure of one: plausible section headers with no traceability to a stated business objective, success criteria that read as reasonable but are not measurable, and acceptance criteria that would not survive contact with UAT. Editing that output into something usable frequently took longer than writing the section from a blank page, since correcting a structurally unsound draft is more labor-intensive than producing a correctly structured one from the outset.

The approach that produced measurable savings

The pattern that consistently saved time was considerably narrower: supplying Q with a requirement that had already been scoped, including the business objective, an in-scope and out-of-scope boundary, and a preliminary list of business rules developed directly with the stakeholder, and asking it to draft the acceptance criteria table and the traceability section against the team's standard BRD template. That is a much more constrained task, and the tool performs it reliably: consistent Given/When/Then phrasing, correct cross-referencing of requirement IDs, and identification of edge cases in the criteria that a human author would likely have added manually regardless.

• Structuring and formatting content against a fixed template returned high value at low risk.
• Drafting acceptance criteria from a rules list the BSA already owned returned high value at low risk.
• Generating the initial business objective or problem statement returned low value; this step still required a human author.
• Any content touching figures the client had not yet confirmed was excluded categorically, treated as a hard boundary rather than a judgment call.

The governance condition that made adoption possible

Every AI-assisted section is visually flagged as such within the working document until a BSA has reviewed and formally signed off, meaning no content reaches a stakeholder without a named human accountable for it. That single control was the basis on which governance approved the rollout; the measured time savings mattered less to the approval process than the demonstrated absence of any reduction in review rigor.

The net outcome across the quarter was a 25% reduction in BRD drafting time, concentrated almost entirely in the mechanical portions of the document, with review standards held constant. Teams evaluating a comparable pilot may find it useful to narrow the task before attempting to measure the tool's impact, since the scope of the task appears to determine the outcome more than the tool itself does.

UAT pass rates across every go-live milestone on the enterprise loyalty program have held in the 90 to 95% range consistently. This is not the product of a testing technique applied at the point of execution; the outcome is largely determined by decisions made weeks before UAT begins, and by the time test cases are being written, most of the result is already fixed.

The determinant is upstream of test case design

Acceptance criteria in this program's BRDs are written in Given/When/Then format from the point of initial drafting, not for stylistic reasons but because the format transfers into a UAT test case with minimal translation loss. Vague acceptance criteria, phrasing such as "the system should handle errors gracefully," convert UAT into a negotiation over what the original requirement was intended to mean, and that negotiation is where pass rates erode. Testable, unambiguous criteria written at the requirements stage is the single highest-leverage input to UAT quality available, and its effect is realized months before a tester opens a test case template.

Defect triage as a feedback mechanism

Every defect logged during UAT is tagged with a root cause category in addition to a severity rating: requirement gap, design gap, build defect, data issue, or environment issue. Over several sprints this categorization becomes a genuinely useful signal. A rising share of defects tagged as requirement gaps indicates that the BRD-to-FRD handoff needs tightening, not that testing needs to be more thorough. Treating defect triage as a feedback loop into the requirements process, rather than solely as a bug-tracking exercise, is what moves the pass rate across successive releases rather than only within the current one.

Entry conditions enforced before UAT begins

• Every acceptance criterion maps to a corresponding test case, with no requirement left without a test and no test written without a traceable requirement.
• Test data is provisioned and validated in the UAT environment prior to day one, rather than discovered as missing on day one.
• Business stakeholders responsible for sign-off are scheduled and confirmed in advance, not merely invited.
• A known-issues list is published before testing starts so testers are not rediscovering defects engineering has already logged.
• Entry criteria are enforced literally: a build that fails smoke testing does not enter UAT on an optimistic assumption that issues will resolve during the cycle.

The reframe for a BSA new to UAT ownership

UAT is better understood as an audit of everything that preceded it than as a discrete testing phase. A low pass rate is rarely a testing failure in isolation; it is typically a requirements or communication failure that has surfaced late in the cycle, at the point of highest visibility and cost. Addressing the earliest point in the chain where ambiguity is introduced has a larger effect on the pass rate than any intervention applied at the testing stage itself.

As the CSM facilitating sprints across a program of more than a hundred people, velocity is the figure I am asked to report every sprint, and I do report it, because leadership expects a trend line. In practice, however, velocity has never once flagged a sprint in trouble before the underlying problem was already visible through other signals. By the point velocity drops, the causal issue has typically been observable for two sprints, in indicators that a velocity-only report does not surface.

Four signals that precede a velocity decline

Repeated carryover is the first. A story spilling into a second sprint is unremarkable; the same story spilling over a second consecutive time indicates a structural problem in how it was scoped or estimated, and velocity will not register this until the second failure has already occurred. Mid-sprint scope additions made without a corresponding trade-off conversation are the second. Not all scope changes are harmful, but silent ones are: an addition without an explicit "what comes out" discussion means the team is absorbing risk that will not appear on the burndown chart until it flattens unexpectedly. Standup length and content drift is the third. When standups extend or shift from blocker-surfacing toward status narration, the underlying cause is usually that the team has stopped expecting a raised blocker to be resolved, which is a signal about psychological safety rather than meeting discipline. Story point inflation is the fourth. Points increasing over time for comparable work is rarely evidence of the team becoming more accurate about complexity; it more often reflects estimate padding introduced because trust in the planning process has degraded.

Why velocity specifically fails as an early indicator

Velocity is a lagging, single-value summary of a problem with several independent dimensions. Two sprints can post identical velocity figures for entirely different underlying reasons, one because the team is genuinely predictable and healthy, the other because the team is managing estimates to hit a target it has learned to distrust. The number is indistinguishable in both cases; the health of the team is not.

What is reported alongside velocity now

Velocity continues to be reported because stakeholders expect the trend line and because removing it would raise more questions than it resolves. Alongside it, the report now includes carryover by repeat offender, a count of scope changes with and without documented trade-off conversations, and a simple retrospective signal: whether the team raised an issue this sprint that it had not raised the sprint before. That last measure is qualitative, but it is the earliest available indicator of whether a team is improving or beginning to disengage, and it typically precedes any movement in velocity by a full sprint.

Having written and reviewed a substantial volume of user stories across the enterprise loyalty program in the capacity of CSPO, a consistent pattern has emerged among stories that cause problems once they reach a sprint: the failure is almost never in the As-a/I-want/So-that format itself, which most authors apply correctly. The format was never the difficult part of the exercise.

A generic or absent "so that" clause

A "so that" clause reading "so that I can use the feature" conveys no information about the underlying business rationale, which leaves the delivery team without the context required to make sound trade-off decisions when scope needs to flex mid-sprint. A properly written "so that" clause names a specific business outcome, for example "so that I do not have to re-enter payment details at every checkout", and that specificity is what allows a developer to resolve an unanticipated edge case in a manner consistent with the story's actual intent rather than a guess at it.

Acceptance criteria that describe implementation rather than behavior

A criterion stating that an API should return a 200 status code is a test assertion, not an acceptance criterion, and it conveys nothing about whether the underlying business need has been satisfied. Acceptance criteria that remain in business language and Given/When/Then structure are directly testable by a non-technical stakeholder during UAT: "Given a returning customer with a saved card, when they reach checkout, then the saved card is pre-selected and the order confirms without re-entry of payment details" is verifiable by anyone familiar with the intended customer experience, not only by QA.

Stories sized to fit capacity rather than split along a value seam

Under sprint-commitment pressure, teams frequently size a story to match available capacity rather than splitting it at a genuine vertical slice of value. The reliable indicator of this problem is a story that cannot be demonstrated independently: if a stakeholder cannot be shown something that functions end to end, the story was likely split incorrectly, irrespective of what the assigned story points suggest.

The template applied to every story before it enters a sprint

1. A story ID and an epic link, so that no story exists without traceability to a larger initiative.
2. The As-a/I-want/So-that statement, written with a named, specific outcome rather than a generic one.
3. Acceptance criteria in Given/When/Then format, kept in business language and testable by a non-technical stakeholder.
4. A MoSCoW priority, which forces an explicit prioritization conversation rather than an assumed one.
5. Story points, sized collaboratively using relative Fibonacci estimation rather than assigned by a single author.

None of these five elements is unusual in isolation. The discipline lies in refusing entry to a sprint for any story where one of the five fields is incomplete or copied from a similar story without verification. A ready-to-use version of this exact template, in the structure described here, is available in the Free BSA Templates section.

The distinction between a BRD and an FRD is one of the first concepts clarified with junior BSAs joining the enterprise loyalty program, because a misunderstanding here does not merely create a documentation inconsistency; it produces scope disputes weeks into a sprint that a clear boundary between the two documents would have prevented. A BRD answers what the business requires and why; an FRD answers what the system will do about it. The two are not the same content in different formatting. They answer distinct questions for distinct audiences.

The Business Requirements Document: the "why"

A BRD is authored for business stakeholders and sponsors. It defines the problem or opportunity driving the initiative, the measurable objectives the initiative must achieve, the scope boundary, and the business requirements themselves, expressed in terms of business outcomes rather than system behavior. A properly written BRD requirement reads as "the business requires a method to identify high-value customers before they churn," not as "the system shall query the CRM database every twenty-four hours."

The Functional Requirements Document: the "what"

An FRD is authored for the delivery team, developers, QA, and architects, and translates each business requirement into specific, implementable system behavior. It traces back to the originating BRD requirement ID, defines data requirements and validation rules, specifies business rules with precision, and addresses non-functional requirements such as performance and security that a BRD typically only references at a high level. Where the BRD states the need to identify high-value customers before churn, the FRD specifies the numeric definition of "high-value," the data inputs used to calculate churn risk, and the frequency at which that calculation executes.

Where the distinction breaks down in practice

Traceability gaps are the most consequential failure mode. When FRD items do not map cleanly to a BRD requirement ID, the delivery team cannot demonstrate that the system addresses the business problem it was funded to solve, and UAT sign-off becomes contentious as a result. A second failure is documentation delivered to the wrong audience: a BRD written in business language sent to developers leaves them inferring implementation detail that was never specified, while an FRD full of data schemas sent to a business sponsor cannot be meaningfully reviewed or approved by that sponsor. A third and more subtle failure is scope creep entering through the gap itself. In the absence of a clean BRD-to-FRD trace, functional requirements can be introduced that were never approved at the business level, and this is the most common origin of the "who approved this" conversation that surfaces during sprint review.

A working rule for new BSAs

If the sentence being written describes what the business wants and why it matters, it belongs in a BRD. If it describes what the system will do in response, it belongs in an FRD. When the distinction is unclear in the moment, identifying the intended reader, a sponsor or a developer, generally resolves which document the content belongs in.

Free templates for both documents, structured as described here, are available in the Free BSA Templates section.