Case Studies

Problem

The platform was live and growing: accounting firms onboarding clients, invoices going out, subscriptions billing through Stripe. But the operator had no way to see which firms were performing, which referral partners were owed what, or which accounts had stopped paying — that data existed in the database, but reaching it meant asking a developer to run a query. For a platform handling hundreds of companies and real revenue, the business was being run without a dashboard.

Solution

A ten-screen admin panel — dashboard, firm and partner management, revenue reporting, overdue accounts, notifications, settings — built as a separate front-end application inside the existing Nx monorepo, sharing one database, one authentication system, and the existing Stripe integration rather than duplicating any of it. Access was granted through the platform's existing auth with role claims, with two-factor authentication and a 15-minute idle auto-logout layered on top, because this account can see every customer's financial data. Delivered fixed-price, fixed-scope, with an architecture document reviewed and approved before any code was written, weekly demos, and an automated test suite as a contractual deliverable, not an afterthought.

Result

The operator can now answer a revenue or partner-performance question by opening a dashboard instead of asking an engineer to write a query — and the admin panel shipped without a single regression to the live customer-facing product it lives alongside.

Problem

The client wanted to build and sell a self-hosted AML (anti-money-laundering) screening portal — the kind of system a bank, real-estate agency, or corporate services firm uses to check whether a customer appears on sanctions lists, is a politically exposed person, or shows up in adverse media. The screening intelligence would come from a third-party provider's API, which on paper made the project sound simple: connect to the API, display the results. It wasn't — and finding out why before signing the contract was the actual work.

Solution

Before quoting, I worked through the provider's full API documentation against the client's UI prototype and found four constraints invisible in the design: a hard rate limit of 3 requests/second shared across every screening call, requiring a server-side throttled queue with retry; a bulk-upload screen promising 100-record batches when the API allows 10, asynchronously, requiring an orchestration layer to split, track, and reassemble sub-batches; adverse-media screening that returns "pending" and calls back later rather than an immediate answer, requiring a signed webhook receiver and an honest loading state; and three advertised features with no API behind them at all, which became an explicit scope decision rather than a mid-build surprise. The estimate was built bottom-up, module by module, cross-checked against a completed reference project, and only the first phase — where requirements were clearest — was fixed-price; later phases were structured to be re-quoted once real delivery velocity was measured.

Result

First phase is in delivery: authentication, the integration layer with its request throttle, case creation, screening results, and full entity/sanctions detail are built and demoed on staging. None of the four hidden constraints became a mid-build surprise, because they were found and priced before the contract was signed.