Louis <> Benford

Product roadmap

01

Product & Architecture

Benford is addressing two main pain points:

  1. For customers, the audit process is inefficient and opaque.
  2. For Benford, the process is time-consuming and too reliant on human workload.

The product should therefore be split into two tools:

  1. External product. A customer portal for uploading information, tracking the audit and communicating with Benford.
  2. Internal product. A back office tool that helps auditors complete work faster through automation and AI.

The external product should be the first visible priority. It is what sells the promise of efficiency and transparency. If customers still need to email documents, manage multiple threads and ask for updates, the product will not feel meaningfully different.

It is also the simpler product to launch. The first version is largely login, file upload, questions, tasks and status tracking.

Work on the internal product should still start from day one, but without a full UI. Engineers can work directly with auditors using scripts, notebooks and lightweight tools. A dedicated interface should only be built once the workflow is clear.

02

External product

Customer needs

  1. Efficiency. Customers need a simple way to upload documents, reuse previous files, preview uploads and see what is still outstanding.
  2. Transparency. Customers need to see the current stage, upcoming stages, expected timings, points of contact and anything blocking progress.
  3. Trust. Customers need secure access, encrypted storage and clear controls over who can view or edit information.

Feature priorities

  1. P0. Basic login, risk-assessment questions, file upload, audit status, timeline and customer tasks.
  2. P1. Customer profiles, file preview, reusable files, detailed stage views and task reassignment.
  3. P2. Full permission management, company roles, chat with auditors and notifications.

03

Internal product

The goal is to reduce repetitive and rules-based work, with a target of at least a 3x improvement in auditor efficiency by the end of Q4.

The product should support auditors, not replace their judgement. It should handle preparation, testing, organisation and drafting, while auditors review exceptions and make final decisions.

P0: Testing phase

Current: 100 hours·Target: 20 hours·Saving: 80 hours

Build a set of automated tests where an auditor can provide data, select the relevant test and generate clear results within hours.

Start with three to five high-volume tests and aim for a 50% saving first. Expand once the results are reliable and trusted by auditors.

P1: Engagement and preparation

Current: 31 hours·Target: 10 hours·Saving: 21 hours

Automate the repetitive work required to set up an engagement, including reusing previous audit information, generating initial information requests, creating tasks and drafting basic planning materials.

P2: Process review

Current: 15 hours·Target: 5 hours·Saving: 10 hours

Help auditors organise walkthrough notes and evidence, draft process descriptions, identify missing information and generate suggested follow-up questions.

AI should support the preparation and drafting, while auditors remain responsible for reviewing controls and making final decisions.

P2: Data ingestion

Current: 10 hours·Target: 2 hours·Saving: 8 hours

Build a standard process for importing client data, mapping fields, validating formats and identifying missing, invalid or duplicate information.

04

Timeline

Delivery roadmap showing the Design, Web, BE1 and BE2 workstreams across 17 weeks

Design

Weeks 1 to 2

Shadow and interview auditors, map the process end to end and identify where the most time is being lost. Speak to customers where possible.

Weeks 3 to 5

Design the P0 external product: dashboard, questions, file upload, status tracker and task view.

Weeks 6 to 8

Design P1 and P2 features, including profiles, preview, permissions and communication.

Weeks 9 onwards

Focus on the internal product once the early tools have been used and the workflow is clearer.

Web development

Phase 1: External MVP

6 to 8 weeks

  1. Set up the web application and agree API requirements
  2. Add basic login using an external provider
  3. Build the risk-assessment question flow
  4. Add file upload and validation
  5. Build the audit status tracker
  6. Build the customer task view

Phase 2: P1

2 to 4 weeks

Add customer profiles, file preview, detailed stage views, reusable files and task reassignment.

Phase 3: P2

3 to 4 weeks

Add permissions, chat, notifications and message history.

Phase 4: Internal UI

Scope this only after auditors have used the headless tools and the workflow has been proven.

Backend development

Split the team into two workstreams: two developers for the external product and four developers plus one data analyst for internal automation.

External product P0

6 to 8 weeks

  1. Set up environments, database, storage, deployment and monitoring
  2. Build APIs for customers, engagements, questions and answers
  3. Build secure file upload, validation and versioning
  4. Build task management and status history
  5. Integrate with web and complete launch testing

External product P1 and P2

5 to 7 weeks

Add profiles, preview, reusable files, detailed stage data, reassignment, permissions, communication and notifications.

Internal testing automation

3 to 4 weeks

  1. Select the first three to five tests with auditors
  2. Agree input and output formats
  3. Build validation and test logic
  4. Generate exception reports linked to source data
  5. Review results and edge cases with auditors

Expand the testing framework

4 to 6 weeks

  1. Add more tests
  2. Standardise how tests are created
  3. Allow tests to run together
  4. Store results and support reruns
  5. Move execution into a shared internal environment

Engagement, ingestion and process review

Add engagement templates, automated requests, reusable mappings, improved data validation, evidence organisation and draft summaries.

05

Design requirements

The external product should feel simple, clear and trustworthy.

  1. Show customers what Benford needs from them
  2. Make the next action obvious
  3. Show what has already been completed
  4. Make the current audit stage clear
  5. Show what is blocking progress
  6. Keep the main point of contact visible

The internal product should prioritise speed and usefulness over visual polish in the early stages.

06

Team

  1. Existing: 4 to 6 BE developers
  2. Mandatory: 1 senior web developer
  3. Mandatory: 1 senior UI/UX designer
  4. Recommended: 1 data analyst
  5. Optional: 1 to 2 additional web developers

The designer does not need audit experience, but must be willing to spend time with auditors and understand the process properly.

07

Stack

  1. Slack for internal communication
  2. Google Workspace
  3. Figma for design and whiteboarding
  4. Jira and Confluence, or Linear
  5. Gemini or another everyday AI assistant
  6. Jupyter Notebook for data analysis, SQL and early scripts

08

MVP

For customers

  1. Simple access
  2. Initial questions
  3. File upload
  4. Status tracking
  5. Tasks

For Benford

  1. Request information easily
  2. Find customer information quickly
  3. Change and track audit status
  4. Run automated tests
  5. Produce clear results for auditor review

Login could be simplified for the earliest customer tests, provided information can still be shared securely.

09

Longer term

  1. Shared customer access with different permission levels
  2. Direct communication with auditors
  3. ERP, accounting, payroll and banking integrations
  4. Microsoft and Google integrations
  5. KYC and company registry data
  6. Automatic collection of agreed client information
  7. Automated data ingestion and testing
  8. Agentic workflows for evidence collection and drafting
  9. Draft working papers and comparisons against previous years

The long-term goal is for Benford to collect more data directly, automate more of the standard work and involve auditors mainly where judgement is required.