Apps for firms

// The problem

An accounting firm chases every client for the same documents each year by email, receives files in pieces, and sends engagement letters and invoices as attachments.

// What we would build

A secure portal for the firm's clients: document requests with checklists and reminders, uploads that land in the right engagement, e-signature for engagement letters, and invoices and payments, connected to the practice management system.

// What is in it

// Stack

• Next.js
• PostgreSQL
• Stripe
• E-signature interface
• Practice management interface
• AWS

// The problem

A consultancy's staff spend hours finding past proposals, reports and methods in shared drives, and new joiners never find them at all.

// What we would build

A search and question tool over the firm's own documents, which answers with the passages it found and links to the sources, so staff can reuse past work. It runs on an open-source model in the firm's own cloud account, because client documents should not reach an outside model provider, and it gives no professional advice of its own.

// What is in it

// Stack

• Open-source model
• Next.js
• PostgreSQL with pgvector
• Document store interface
• AWS

// The problem

An architecture practice sees time in one system, invoices in another and project budgets in spreadsheets, and learns a project ran over only when it is finished.

// What we would build

A dashboard that reads time, billing and project budgets into one model, so partners see utilisation by person and team, and budget used against fees earned on every project, week by week.

// What is in it

// Stack

• Next.js
• PostgreSQL
• dbt
• Time and billing interfaces
• DigitalOcean

// The problem

A bookkeeping firm retypes invoices and payments from its practice management system into QuickBooks Online, and the two never quite agree at month end.

// What we would build

A two-way integration between the practice management system and QuickBooks Online, with a small admin screen, so invoices, payments and clients are entered once and stay in step, with every change logged.

// What is in it

// Stack

• Next.js
• PostgreSQL
• QuickBooks Online API
• Practice management interface
• DigitalOcean

// The problem

An engineering firm is sometimes asked to prove which version of a report or drawing it issued, and when, and its file server dates are easy to dispute.

// What we would build

Each issued deliverable's fingerprint is recorded on a public blockchain at the moment it is issued, so the firm can later show that a file existed in that exact form at that time without revealing its contents. If an internal log your clients already trust is enough, a database is simpler, and we will say so.

// What is in it

// Stack

• Next.js
• Solidity
• Base
• PostgreSQL
• DigitalOcean

// The problem

A consulting firm's resourcing and proposal tool was built in-house years ago, runs on one old server, and nobody left at the firm can change it.

// What we would build

We review the old tool, write down what it does, and rebuild it as a supported web app with the data moved across and checked, running both side by side until the firm is ready to switch the old one off.

// What is in it

// Stack

• Next.js
• PostgreSQL
• AWS
• Terraform

// The problem

A consultancy wants to turn a method it sells as advice into a paid web product for clients, and has nobody to plan the technology, hire for it or check a vendor's quote.

// What we would build

A fractional technical lead who reviews the idea, writes the plan and the build-or-buy choices, and then leads the first version: a client web app with sign-in, subscriptions and reports. The estimate here prices that first build; the review comes first and is quoted on a call.

// What is in it

// Stack

• Next.js
• PostgreSQL
• Stripe
• AWS