Turn domain expertise into a software specification

A buildable brief connects a real input to rules, expected output, and acceptance checks. This worked example shows what the developer receives.

Discuss your workflow See the filled-in brief

01 / Sample input

B-104.pdf

Usage: 1,200 kWh
Total: PLN 960.00

02 / Domain rule

No billing period? Keep it in review.

03 / Acceptance checkOnly approved bills reach the report.

One example the expert and developer can verify

Flatlogic products and services are used all over the world, including the following notable companies

What belongs in the first brief?

Here is a filled-in brief for one utility-bill workflow. The company, bill, values, and rules below are illustrative.

Workflow

A finance reviewer uploads a bill, checks extracted fields against its PDF, and approves a record for the company's report.

Users and access

An uploader adds bills. A reviewer corrects and approves them. Files and records belong to the signed-in user's company and are visible only within that company.

Sample input

PDF bill B-104 for Acme Bakery, site Warsaw-01: September 1–30, 2026, 1,200 kWh, and PLN 960.00. The uploader belongs to Acme Bakery.

Rules and exceptions

AI proposes values from the PDF. Code blocks approval without a site, billing period, usage, or total. A reviewer checks the source, resolves discrepancies, and approves the record.

Expected output

The approved-bills report contains B-104, Warsaw-01, September 1–30, 2026, 1,200 kWh, and PLN 960.00. The record retains its source PDF and approver.

Release boundary

PDF upload, review, approval, and one approved-bills report. Forecasting, payment collection, and accounting integrations remain outside this first release.

Four steps from expertise to an agreed scope

The domain expert supplies the examples. The developer makes the rules explicit. Each step produces something both can review.

Walk through a real example

The domain expert shows a bill and the report it should produce. The developer follows every action. Output: one sample input, its expected result, and the people involved.
Make the exceptions explicit

Repeat the walkthrough with a missing billing period and an incorrect amount. Who can fix each problem? Output: required fields, approval rules, access rules, and exception cases.
Draw the first release boundary

Include PDF upload, review, approval, and one report. Defer forecasting, payments, and accounting integrations. Output: a short scope that separates the first release from later work.
Review the brief together

The developer explains the workflow back to the expert. Both confirm the five expected results below and record unresolved questions. Output: an agreed brief for a development estimate.

How do we know the brief is implemented?

Each case below has an observable result. The domain expert confirms these results before development.

Five acceptance checks for the example brief
Test case	Expected result
Approved bill	Included. B-104 appears in the report with the exact values above. Its source and approver remain available.
Missing period	Blocked. The missing field is identified. B-104 stays in review and cannot be approved.
Wrong extraction	Corrected. AI proposes PLN 9,600.00. The reviewer checks the PDF and corrects it to PLN 960.00. Approval saves that value.
Another company	Denied. Its user cannot read or change B-104, or open the PDF through a direct link.
Before approval	Excluded. B-104 stays out of the approved-bills report.

The developer turns these examples into tests. When a domain rule changes, the expert updates the expected result with the developer. The affected tests run again before release.

Watt Footprint utility analytics in light and dark themes

Related delivery: Watt Footprint

Watt Footprint is an actual delivery example: Flatlogic turned energy workflows into an owned SaaS product with bill capture, review, dashboards, and ongoing releases.