Job management for small trades businesses.

1Summary

Small trades businesses, such as plumbers, electricians, heating engineers and joiners, run most of their work from a phone, a notebook and a spreadsheet. Quotes are written in the evening, job details live in text messages, and invoices go out days after the work is done, which slows down cash flow for businesses that can least afford it.

The product we propose turns a customer enquiry into a quote, a booked visit, a completed job and a paid invoice, all from the phone, and works on site where mobile signal is poor. The office side, often a partner or a part time administrator, uses a web app to see the diary, chase quotes and check who has paid.

Established competitors already serve larger trades firms with broad feature sets. Our view is that there is room for a product aimed tightly at the sole trader and the small team, priced simply, quick to learn in an evening, and built around getting paid on the day. The first version should do that one journey well and leave everything else out.

We recommend going ahead with a three month build, provided the evidence tests below are passed in the first two weeks.

2Customer and problem

Who it is for

The first customer is an owner who works on the tools, employs up to four people, and handles quotes and invoices personally. A second user is the person who helps with the paperwork, often working part time from home.

The problem in their words

These are the problems we expect to hear in interviews. They are hypotheses until the interviews confirm them.

• Quotes take too long to write and look unprofessional when they are sent as a text message.
• Customers forget what was agreed, and there is no simple record of photos, notes and sign off.
• Invoices go out late because they are written up at the end of the week.
• Chasing payment is awkward, and bank transfers are hard to match to jobs.
• Existing software feels built for a larger firm with an office manager.

What success looks like for the customer

The owner sends a quote from the van within ten minutes of leaving the customer, finishes the job with photos and a customer signature on the phone, and has the invoice paid by card or bank payment before driving away, or within a few days through a payment link.

3Evidence to gather before the build

The build should start only when these tests are met. Each one has a pass mark agreed in advance.

If the switching test fails, the product is not worth building as a standalone business. If only the price test fails, we would rework the pricing and test again before committing to the build.

4Scope of the first version

In scope

• Sign up for a business, invite up to ten team members, and set roles for owner, office and engineer.
• Customers and sites, with UK address lookup and notes.
• Enquiries captured by hand or from a web form the business can put on its own site.
• Quotes built from a saved price list, with labour, materials and VAT, sent as a branded PDF and a link the customer can accept online.
• A diary showing visits by person, with drag and drop on the web and a day list on the phone.
• Job sheets on the phone with checklists, photos, notes, materials used and a customer signature, working offline.
• Invoices created from the job in one step, sent by email and text, with a card and bank payment link.
• Payment status, automatic reminders and a simple list of who owes what.
• Export of invoices and payments to CSV for the accountant.

Out of scope for the first version

• Accounting software integration, which comes second, starting with the most requested package from the pilot.
• Stock control, purchase orders and supplier price feeds.
• Timesheets, payroll and vehicle tracking.
• Certificates for regulated work, such as gas safety records, which carry their own compliance requirements and should be scoped separately.
• Customer booking portals and marketing tools.

5Main user journeys

6Architecture overview

The product runs on AWS in the London region (eu-west-2), using serverless services wherever they fit, so running costs stay low while customer numbers are small and rise in line with use. One React codebase produces the web app and the iOS and Android apps: the web build is served through CloudFront, and the same build is packaged as native apps with Capacitor, which gives access to the camera, local storage, push notifications and location. The mobile apps work offline and sync when signal returns. Both share one API and one data model.

A small number of external services do specialist jobs better than we could build them: Stripe for payments, Resend for email, Cloudflare for DNS, bot protection and the marketing site, Matomo for product and marketing analytics, Sentry for error tracking, and Firebase Cloud Messaging for push notifications.

Components

7Technology and frameworks

We use current stable releases and pin exact versions in the repository at the start of the build. Where the newest release is not yet supported by a managed service, we use the newest supported release and record the upgrade as a planned task.

8Infrastructure definition

AWS accounts and regions

All infrastructure is defined in code and deployed through the pipeline. Nothing is created by hand in the console, except the initial organisation set up.

Primary region is Europe (London), eu-west-2. CloudFront certificates and the CloudFront WAF web ACL sit in us-east-1 because AWS requires it. Backups are copied to Europe (Ireland), eu-west-1. Service control policies block other regions, stop CloudTrail being turned off, and stop public S3 buckets being created.

Cloudflare

Cloudflare holds the domain and the authoritative DNS, with DNSSEC switched on. Records for the app, the API and file downloads point to CloudFront with the Cloudflare proxy off, so AWS WAF and CloudFront are the only layer in front of the application and requests are not inspected or cached twice. The marketing site runs on Cloudflare Pages with the proxy on, behind Cloudflare WAF managed rules and rate limiting. Turnstile protects the sign up form, the waiting list, the public enquiry form and the customer quote and invoice pages, and the API verifies each Turnstile token before acting on the request. Resend's SPF, DKIM and DMARC records, and the Matomo tracking domain, are kept in the same Cloudflare zone, all managed from the pipeline.

Network

Stacks

Example CDK structure

// infra/bin/app.ts
const app = new cdk.App();
const env = { account: process.env.CDK_DEFAULT_ACCOUNT, region: 'eu-west-2' };
const edgeEnv = { account: process.env.CDK_DEFAULT_ACCOUNT, region: 'us-east-1' };
const stage = app.node.tryGetContext('stage') as 'dev' | 'staging' | 'prod';

const network = new NetworkStack(app, `${stage}-network`, { env, stage });
const data = new DataStack(app, `${stage}-data`, { env, stage, vpc: network.vpc });
const storage = new StorageStack(app, `${stage}-storage`, { env, stage });
const identity = new IdentityStack(app, `${stage}-identity`, { env, stage });
const asyncStack = new AsyncStack(app, `${stage}-async`, { env, stage, vpc: network.vpc, data, storage });
const api = new ApiStack(app, `${stage}-api`, { env, stage, vpc: network.vpc, data, storage, identity, bus: asyncStack.bus });
new MessagingStack(app, `${stage}-messaging`, { env, stage });
new EdgeStack(app, `${stage}-edge`, { env: edgeEnv, crossRegionReferences: true, stage, storage, api });
new SecurityStack(app, `${stage}-security`, { env, stage });
new ObservabilityStack(app, `${stage}-observability`, { env, stage, api, data, asyncStack });

// infra/lib/data-stack.ts (extract)
const cluster = new rds.DatabaseCluster(this, 'Db', {
  engine: rds.DatabaseClusterEngine.auroraPostgres({ version: rds.AuroraPostgresEngineVersion.of('18.6', '18') }),
  writer: rds.ClusterInstance.serverlessV2('writer'),
  readers: props.stage === 'prod' ? [rds.ClusterInstance.serverlessV2('reader', { scaleWithWriter: true })] : [],
  serverlessV2MinCapacity: props.stage === 'dev' ? 0 : 0.5,
  serverlessV2MaxCapacity: props.stage === 'prod' ? 8 : 2,
  vpc: props.vpc,
  vpcSubnets: { subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS },
  storageEncrypted: true,
  storageEncryptionKey: dbKey,
  backup: { retention: cdk.Duration.days(props.stage === 'prod' ? 35 : 7) },
  deletionProtection: props.stage === 'prod',
  cloudwatchLogsExports: ['postgresql'],
});
const proxy = cluster.addProxy('Proxy', { secrets: [cluster.secret!], vpc: props.vpc, requireTLS: true, iamAuth: true });

// infra/lib/edge-stack.ts (extract)
const acl = new wafv2.CfnWebACL(this, 'AppAcl', {
  scope: 'CLOUDFRONT',
  defaultAction: { allow: {} },
  visibilityConfig: { cloudWatchMetricsEnabled: true, metricName: `${props.stage}-app-acl`, sampledRequestsEnabled: true },
  rules: [
    managedRule('AWSManagedRulesCommonRuleSet', 10),
    managedRule('AWSManagedRulesKnownBadInputsRuleSet', 20),
    managedRule('AWSManagedRulesAmazonIpReputationList', 30),
    managedRule('AWSManagedRulesAnonymousIpList', 40),
    managedRule('AWSManagedRulesSQLiRuleSet', 50),
    managedRule('AWSManagedRulesBotControlRuleSet', 60),
    rateRule('SignInRate', '/v1/auth', 100, 70),
    rateRule('SyncRate', '/v1/sync', 600, 80),
    rateRule('PublicLinkRate', '/v1/public', 120, 90),
  ],
});

Environments and releases

Database migrations run as a separate pipeline step before the new Lambda code is switched on, and each migration must work with both the old and new code so a release can be rolled back.

9Data model

All business data carries a tenant_id. PostgreSQL row level security policies restrict each query to the tenant in the caller's token, so a fault in application code cannot return another business's records. Identifiers are UUIDv7, generated on the device, so records created offline keep the same ID once synced.

Money is stored as integer pence with an ISO currency code. VAT is calculated per line and rounded per line, matching the way most UK invoices are presented, and the rounding rule is covered by tests.

10API design

The API is a JSON API over HTTPS, versioned in the path. Requests from the apps carry a Cognito access token. Public customer links use signed tokens that expire and identify one quote or invoice only.

Errors follow RFC 9457 problem details. Writes accept an idempotency key so a request retried after a dropped connection does not create a duplicate quote, invoice or payment.

11Detailed design

Offline working and sync

The mobile apps keep an encrypted SQLite copy of the user's upcoming visits, their jobs, customers and sites, the price list and open quotes. The encryption key is generated on first sign in and held in the iOS Keychain or Android Keystore. Every change on the device is written locally first and added to an outbox. When the Capacitor Network plugin reports a connection, the app pushes the outbox in batches and then pulls changes from the server since its last sync point. The web app works online only in the first version.

The server applies each change with a version check. If the record has changed on the server since the device last saw it, field level rules decide the outcome: notes and checklist answers are merged, the job status follows a fixed order so a completed job is not reopened by a stale device, and price fields keep the server's version and flag the conflict to the office. Photos are compressed on the device, written to app storage with the Filesystem plugin and uploaded separately in the background, resuming after a dropped connection, so a job sheet can sync before its photos have finished.

Mobile app shell

The Capacitor apps load the React build from the app bundle, not from a remote URL, so the app opens and works without signal. Native features are reached only through the Capacitor plugins listed in section 6, wrapped in one module so the web build falls back cleanly where a feature does not exist in the browser. The apps request camera, location and notification permissions at the point of use, with a plain explanation. Updates to the web layer ship through the app stores in the first version; over the air updates can be added later within Apple and Google rules.

Quotes and invoices

Quote and invoice numbers are generated per business from a database sequence so they are gap free and in order, which accountants expect. PDFs are produced by a worker from React templates, stored in S3 with the document version, and regenerated only when the document changes. Once an invoice is sent, its lines are locked; changes are made by issuing a credit note and a new invoice, so the record matches what the customer received.

Payments

Each business connects its own Stripe account through Stripe Connect onboarding, so customer payments go straight to the business and we do not hold client money. The invoice link opens a Stripe Checkout page offering card, Apple Pay, Google Pay and bank payment where Stripe supports it for the account. Payment status is updated only from Stripe webhooks whose signatures are verified, processed once using the event ID. Cash and bank transfers can be recorded by hand by the owner or office user.

Email through Resend

Workers send quotes, invoices, reminders, invitations and sign in codes through the Resend API, using React Email templates branded with the business's name and logo. Mail is sent from a subdomain dedicated to transactional email, with SPF, DKIM and a DMARC policy published in Cloudflare DNS, and the reply address set to the business's own email. Each send carries an idempotency key so a retried worker does not send twice. Resend webhooks, verified by signature, record delivery, bounce and complaint events against the customer, so the office can see when an email address is wrong, and repeated bounces stop further sends to that address. Cognito sign in codes go through a custom email sender trigger that decrypts the code with KMS and sends it through Resend, so all email comes from one service with one set of records.

Reminders

When a quote or invoice is sent, the API creates EventBridge Scheduler schedules for the follow ups the business has chosen, for example three, seven and fourteen days. Each schedule puts a message on a queue, and the worker checks the record is still unpaid or unaccepted before sending anything. Paying or accepting cancels the remaining schedules.

Push notifications and texts

The Capacitor Push Notifications plugin registers each device with Firebase Cloud Messaging, and the API stores the device token against the user and the device. Workers send notifications for new or changed visits through the FCM HTTP v1 API, which delivers to Android directly and to iOS through Apple Push Notification service. Notifications carry no customer details, only a prompt to open the app. Texts to customers go through End User Messaging with the business name as the sender ID.

Identity and roles

Business users sign in with passkeys or an emailed code, and owners can require MFA for their team. Cognito threat protection blocks sign in attempts that use known leaked credentials and challenges unusual sign in patterns. Tokens are kept in secure storage on the device and refreshed silently. Roles are held in the database and copied into the token at sign in. Engineers see their own visits and the jobs assigned to them; office users see everything except billing settings; owners see everything. Removing a team member revokes their sessions and their device copy is cleared at the next sync.

Analytics with Matomo

Matomo Cloud, hosted in the EU, measures the marketing site, the sign up funnel and how the apps are used. The marketing site runs Matomo without cookies, so no consent banner is needed there. The web and mobile apps ask for consent before tracking, record events by feature such as quote sent or invoice paid rather than by customer, and do not send customer names, addresses or amounts. Goals in Matomo match the launch measures in section 17, so the pilot dashboard and the product analytics agree.

Search and lists

Lists in the web app are paged on the server, with indexes on tenant, status and date. Customer search uses PostgreSQL trigram indexes on name, email, phone and postcode, which is enough for businesses at this size without a separate search service.

12Security and privacy

13Quality, testing and releases

Each change goes through a pull request with automated checks: type checks, lint, unit tests, API tests against a disposable PostgreSQL database, a CDK synth and diff, a Terraform plan for Cloudflare, and security scans. Web end to end tests run with Playwright against staging. Mobile flows, including working offline and syncing afterwards, run with Maestro on iOS and Android builds produced by the pipeline.

Releases to production need passing checks and a named approver. The web app is released by uploading the new build to S3 and invalidating CloudFront. Mobile releases are built and signed in CI with fastlane, go to TestFlight and the Play internal track first, and are then released to the stores in stages. Sentry receives the source maps and release version for each build, so errors can be traced to the exact release.

14Monitoring and support

Each request carries a trace ID from the app through the API to the database and the workers, using AWS X-Ray through OpenTelemetry. Monitoring is split by what each tool does best.

Alarms go to the support rota through SNS, with a runbook linked from each alarm. Service levels for the first version are 99.5% monthly availability for the API and web app, with a recovery point objective of 5 minutes and a recovery time objective of 4 hours, both tested before launch by restoring a backup into staging.

15Running cost estimate

These are our estimates, before Stripe fees, text message charges and app store fees. They assume modest use at each stage and should be confirmed at the start of the build with the AWS Pricing Calculator and the current plans of each external service, because London prices differ from the US list prices AWS uses in its examples and external plans change.

The largest fixed AWS items are NAT gateways, RDS Proxy, AWS WAF with Bot Control, and the minimum database capacity in production. Texts cost more per message than emails, so text reminders are off by default and switched on per business.

16Build plan

The build follows our standard three month plan. A senior architect leads the build and makes the design decisions, AI agents do the heavy lifting on code, tests and documentation, and a product lead runs the pilot recruitment and customer testing.

Milestones and stop criteria

17Launch plan

The pilot runs with ten businesses recruited from the interviews and waiting list, free for the first two months in return for weekly feedback. Public launch follows when the pilot measures below are met for four weeks in a row.

Pricing to test at launch is a monthly subscription per business, with one price for a sole trader and one for a team of up to ten, plus card fees passed through at cost. The channels to test first are trade communities online, a trade supplier partnership with counter promotion, and referrals from accountants who serve trades businesses.

18Risks

19Decisions for you

• Confirm the first customer group, including whether to start with one trade or several.
• Choose the product name, so domains, app store listings and the sender ID can be registered in week 1.
• Agree the pilot terms, including the free period and what pilot businesses commit to.
• Choose who takes the product on after the build: your own senior technology team or a development partner you trust, so the handover pack is written for them.

20What the build hands over

At the end of the build, the receiving team gets the code in your own repository, the AWS accounts in your own organisation, the Cloudflare, Resend, Stripe, Matomo, Sentry, Firebase and app store accounts in your name, and a documentation pack covering the architecture and decision records, the data model, the API reference, the CDK stacks and Cloudflare configuration, the monitoring dashboards and alarms, runbooks for releases, incidents, backups and restores, the threat model and security test results, the cost model, the pilot results and the open backlog. We walk the receiving team through it, they make a release themselves with us alongside, and the build is accepted when they confirm they can run, change and support the product.

* All prices are subject to VAT.