Build the team
Not a rented crew that rotates. People whose level was known in advance, assembled fast enough to start inside the three-month window.
Case study - FinTech · Working capital · United Kingdom
EarlyAce
Working capital optimization platform
A cloud platform for a B2B early-payment network. Buyers put idle cash to work by settling supplier invoices ahead of their due date at a discount; suppliers get paid when they need the money rather than when the invoice matures; and a real-time exchange engine in the middle matches the two sides. Built from zero with a team I helped assemble - MVP in three months, full v1 inside a year.
- Role
- Lead Developer
- Scope
- Turn-key product design & development - team, process, product
- Industry
- FinTech / Supply chain finance
- Location
- London, United Kingdom
- Team
- 5, plus a consulting cloud architect
- Duration
- 1.5 years
- Technologies
- C# / ASP.NET Core · MS SQL Server · Dapper · IdentityServer · SignalR · Angular · Azure
01 The challenge
A second attempt.
No room to fail.
The founder came to me with a clear product vision, a budget, and a very direct brief: be the Lead Developer, help assemble a team, deliver an MVP in three months, then take that team all the way to a full production product.
There was history behind that brief. His first attempt at the platform had failed - a weak technical foundation, tech debt accumulating faster than features, and team conflicts that eventually broke the project apart. This time he wanted it done right: a clean architecture from day one, and a team he could actually rely on.
The domain raised the bar again. A B2B early-payment network runs on real money between real companies - but the platform never moved a penny of it. It calculated the offers, matched the two sides and issued the invoices; the payment itself happened at the bank. Which means every number it produced had to be right the first time, with no tolerance for a rounding error, because a real company was about to pay against it.
Build the process
A way of working that would surface a misunderstanding in days rather than at the end - because the last attempt died on communication as much as on code.
Build the product
A financial exchange with two portals, live state on both sides, and calculations the founder could put in front of real companies.
02 The outcome
Three months to MVP.
Then the whole product.
3 monthsWorking MVP delivered
~10 monthsFull v1, on schedule
1.5 yearsSame team, start to finish
The MVP landed in the founder's hands in three months, on a clean architecture with no legacy debt behind it. Full v1 followed on schedule, roughly ten months from kickoff, with all core modules live and production-ready.
The platform went live with its first real customers - the product thesis was tested in the market rather than on slides. And the founder had a delivery rhythm he could plan around: every week he tested the previous iteration while the team built the next, so risks surfaced early instead of at the end. The team stayed intact and effective for the full 1.5 years, without losing pace or quality.
The company went on to raise investor funding over the following years - something the founder credits directly to the team's work. His words, at the end of this page, not mine.
The platform ran with real customers. Where the company went after that was the founder's call, made after my work had finished.
03 The system
Not a trick.
A system.
What made the second attempt work was not one clever decision. It was five - and each one answered a specific way the first attempt had died.
- 01
A team I already trusted
I did not hire from a stack of CVs. I helped the founder assemble the team from engineers I had worked with before and whose level I knew first-hand: two developers, a designer working closely with the founder, and QA. For the cloud foundation I brought in a consulting architect. No surprises in quality; that risk was removed on day one.
- 02
Clean architecture from day one
No inherited codebase, no legacy debt. The application was designed fresh for the product it needed to become. Within the architecture vision laid down with the consultant, the day-to-day technical decisions inside the application - data layer, application design, integrations - I drove together with the team.
- 03
One communication channel, zero lost context
All client communication ran through me. The founder acted as Product Owner - he knew exactly what he wanted - and my job was to move that into the team without distortion. I sat on every design call as the mediator between the founder and the designer, bridging both a language gap and an understanding gap, so what got built matched the vision in his head rather than a translation of a translation of it.
- 04
A weekly delivery cycle built for trust
Weekly iterations backed by CI/CD. Each week's build shipped to the founder, who tested the previous week's functionality while we developed the next. I defined the delivery workflow and owned the process; the team implemented the pipeline. He watched the product grow every single week, and any misunderstanding cost days instead of months.
- 05
One accountable person
Team, process, client relationship and code - the threads all met in one place. No handoffs where context dies, no "whose job was that?". Roughly half of my own time went into full-stack development alongside the team; the other half into communication and coordination.
04 The product
Two portals.
One exchange.
Buyers with cash on one side, suppliers waiting on invoices on the other, and an engine in the middle deciding who gets paid early and at what discount - recalculated while the session is still open.
Screenshots come from a demo environment - all company names and figures on them are fictional.
Buyer portal and invoice management
The heart of the platform. Businesses upload and manage supplier invoices, open early-payment sessions, and watch discount capture move in real time: amount on the table, funds allocated, return achieved, participating suppliers, and the time left before the session closes.
Supplier portal
Suppliers get on-demand access to early payment: which invoices are clearing, what the discount costs, what the new amount comes to, and a paperwork-free way to accept early settlement. One account, one switch between the two sides of the network.
The exchange engine
A real-time algorithm matching each buyer's available cash against the discount offers on the supplier side - the financial core of the network. Whatever number it produced went onto an invoice a real company then paid at the bank.
Real time everywhere
Live data updates and notifications over SignalR, so every side of a payment session sees the same state at the same moment. Behind both portals sits an admin surface: company and user management across the network, system configuration, and automated reporting.
05 Under the hood
One number.
Everyone, at once.
C# on ASP.NET Core with Dapper over MS SQL Server; IdentityServer covering two portals and an admin surface; SignalR for live state; an Angular SPA built around a user-centric UX architecture. All of it running on Azure.
Every piece of it is enterprise-grade and vendor-backed - Microsoft's own .NET and SQL Server, Google's Angular - not a shelf of unproven libraries. The choice was to sit on the modern edge of that stack rather than its legacy end: current tools, picked because a financial product has to be maintained and trusted for years, not because they were new.
Real time is the constraint that shapes the rest. A payment session is a countdown: the buyer, the supplier and the engine all have to be looking at the same number at the same moment. In a financial exchange, stale data is not a UX problem - it is a wrong answer.
06 Who did what
Five people.
One accountable.
I joined as Lead Developer - the founder's own title for the role, not one I gave myself. In practice it meant holding every thread at once, and being the person who answered when one of them pulled.
Mine
- The team - helped the founder assemble it, then kept it intact and effective for a year and a half
- The client relationship, end to end - vision transfer, design mediation, weekly demos, expectations
- The delivery process - the agile framework, the weekly cycle, the CI/CD workflow
- Technical decisions inside the application
- Full-stack development - roughly half my time, alongside the team
Not mine
- Product direction and prioritiesThe founder, as Product Owner
- The cloud architecture foundation - drawn together, not by me aloneConsulting Azure architect
- UI designA designer on the team
- QAA dedicated tester on the team
I am not a narrow deep-specialist. I am the person who connects the parts - the founder's vision, the design, the engineering, the process, and the software that actually ships. On this project that was exactly what was needed.
Why it mattered to the founder: after a first attempt that collapsed under tech debt and broken communication, he had one accountable person between his vision and the codebase. Faster decisions, no context lost in a handoff, and a product he could check week after week instead of discovering at the end.
07 The review
In his words.
Not mine.
As a direct result of Alex's work, my company raised £300k in investor funding over 3 years and built a very impressive application.
Alex helped hire and manage a talented team of 4 (2 developers, 1 designer and a tester). His skills as a developer and manager were very impressive. He helped keep the team motivated even during the tough times of the startup journey.
... I would wholeheartedly recommend Alex.
Simba Chiguma on LinkedIn (opens in a new tab)Founder · EarlyAce Limited
Signed reference 08 Contact
Building something
like this?
On EarlyAce, one person held the delivery together - the client relationship, the team, the process and the code - and stayed for the whole thing. That is still how I work, now solo and AI-augmented rather than with a crew of five. Building a product with a small, fast team and want one person accountable end to end?
alex@cyber-architects.com