Extranet B2B
Two businesses, three platforms, one codebase — and forms the business changes without a redeploy.
An equipment-finance company was running its business through email and phone calls. This extranet moves it to self-service: partners build their financing applications, customers follow their contracts, and it all happens in one place — on web, iOS and Android.
- Category
- Cross-platform business platform
- Platforms
- Web · iOS · Android
Where it started
Some details of this project are confidential and are not shown here.
Equipment finance puts two very different populations to work together. On one side, partners — resellers and brokers — who build applications and need a fast answer. On the other, the customers themselves, who simply want to know where their contracts stand. Both went through the same channels: an email, a call, an attachment that goes missing.
Serving both audiences properly meant two products. Building two, then shipping each to web, iOS and Android, would have taken several teams and multiplied the places to fix the same bug. The business also moves: forms, rate scales and validation rules change, and every change could not mean a new release across three platforms.
What was built
A single Flutter codebase serves all three platforms and both business areas, sharing their frame and diverging where the business demands it: permissions, screens, rules. Partners simulate financing, build an application, send a contract for e-signature. Customers consult their contracts, schedules and invoices. And crucially, the forms are described by the server: the business changes them without a single line of the app changing.
What the product does
Simulation and application build-up
Amount, term, frequency, rate scale, maintenance: partners simulate financing, then turn the simulation into an application.
Electronic signature
Send the contract to the right signatory and follow the signing cycle, down to verifying the signatory’s mobile number.
Contract tracking
Searchable list, financial detail, schedules, equipment, invoices and arrears tracking.
Two areas, one account
The same user switches between the partner and customer areas, with fine-grained permissions per feature.
Document management
Attachments, a document library, and automatic chasing of missing paperwork.
Dashboards
Activity, announcements and indicators: applications, arrears, performance per salesperson.
The decisions that mattered
Forms the business changes without a developer
The fields are not written into the application: they are described by a schema served by the API, and the app builds them on the fly. In practice, adding a field or changing an input rule needs no development, no QA cycle and no release across three platforms — the business evolves its form and the change is live everywhere, immediately. This is the decision with the greatest effect on the product’s cost of ownership.
Two products inside one application
Partners and customers share the frame but diverge on permissions, screens and rules. The classic trap is stacking conditionals until nobody dares touch the code. The answer was genericity: a shared form engine, parameterised by type, and shared components — fields, paginated lists, responsive structures. A bug is fixed in one place, for both businesses and all three platforms.
An interface decoupled from the API
The layers are strictly separated: the interface has no idea where the data comes from. The consequence is concrete — a feature was built entirely against simulated data, then wired to the real API by changing a single file. API data models are explicitly converted into business objects, so a change to the server contract does not ripple through the product.
Real responsive, not a resize
A sortable table of several hundred contracts makes no sense on a phone. So every screen exists in two forms: sortable columns and tables on the web, lists and infinite scroll on mobile. Search is paginated server-side, because at this volume, loading everything is not an option.
Financial input, where the bugs hide
Amounts, rates, terms: a comma instead of a period, one decimal too many, and the application is wrong. Financial fields are therefore constrained by dedicated formatters, and the rules for rate scales, maintenance and validation are tested — because on a financing application, an input error is not a cosmetic detail.
How it fits together
Flutter
One codebase for web, iOS and Android — two business areas
Cubit
Screen state, isolated from the interface and testable
Use cases & repositories
Business rules, independent of where the data comes from
API REST
The existing core system, behind an enterprise gateway
The technologies used
Frontend
- Flutter
- Dart
- BLoC
- Freezed
- go_router
Backend
- API REST
- JWT
Infrastructure
- Docker
- GitLab CI
- Fastlane
Services
- Firebase Cloud Messaging
What was delivered
Extranet delivered on web, iOS and Android from a single codebase, covering simulation, application build-up, e-signature, contract and arrears tracking, and document management, across two distinct business areas. The delivery pipeline is automated over four environments, from containerised web to store publication. Some details of this project remain confidential.
- Web
- iOS
- Android
Need a similar product?
Let’s talk about what you want to build. I reply personally, usually within 24 hours.