Costblok

The problem

Quantity surveyors run development feasibility in spreadsheets they have trusted for years: land, construction, fees, finance, sales and rental, rolled up into returns a bank will lend against. Costblok moves that work into a subscription product that teams can collaborate on.

The core challenge is total accuracy. The product’s credibility rests entirely on its numbers: if one figure disagrees with the spreadsheet a QS already trusts, the tool is finished.

What I built

A financial engine and the product around it, first in FlutterFlow and now as a React rebuild with a redesigned schema.

• Feasibility studies

  Multi-section studies covering land, construction, fees, general, finance, sales and rental, rolled up into a cost summary with net return, IRR, NPV and cashflow.

• Project payment summaries

  Budget control and monthly payment tracking: spend by month, contractor payments and category-based financial summaries.

• Bank-ready reports

  Generated PDF reports built to go straight to a lender.

• Teams and billing

  Projects shared with owner, editor and viewer roles, and Paystack subscription billing and invoicing gating the paid editing features.

My role

Head developer and the client’s direct contact. I built the financial engine, feasibility returns across seven currencies, Paystack subscription billing and invoicing, and the PDF reports.

The original product was FlutterFlow. I authored about 97% of the current React rebuild: React 19, Supabase/Postgres, Deno edge functions and Paystack.

Key decisions

1. Maths in TypeScript, not triggers

   The original schema computed totals through chains of database triggers. The rebuild moves every formula into a pure TypeScript domain engine with tests, which reproduces the source spreadsheet exactly and writes derived totals explicitly.

2. Keep the number users recognise

   Where the source spreadsheet and the old app defined net yield differently, the rebuild keeps the figure users have always seen. Switching would have silently changed a headline number.

3. Local-first, with security as a launch gate

   The rebuild is developed against local Supabase with versioned migrations, never against the legacy production database. Row-level security and secure grants must pass before anything launches.

Outcome

Spreadsheet parity

The domain engines reproduce the source spreadsheet exactly, with tests to prove it.

Honest inputs

Periods derived from programme dates instead of defaults nobody checked.

Easier to change

Formulas in tested code, not hidden in trigger chains.

Stack