Custom portals, marketplaces and operational platforms built around your business model

A custom platform makes sense when the rules that set your business apart, such as how you price, match, approve or pay, cannot be expressed in a packaged product without manual work around it. Marketplace builders and multi-vendor plugins handle standard listings, checkout and simple commission well, and if your model fits one through configuration alone, starting there is quicker. The case for building appears when workarounds, plugin conflicts and reconciliation spreadsheets cost more each month than owning the platform would.

Yes. Where the payment provider supports it, such as Stripe Connect in the UK and many other markets, the platform charges the buyer once, keeps its commission and routes the remainder to each vendor, with refunds and chargebacks assigned to the right party. Where split payments are not available, as with some regional gateways, the platform collects funds, records what each vendor is owed in a ledger and runs scheduled payouts that finance reviews. Your advisers confirm any payment licensing implications.

We build each of them as a workflow with clear states, owners and records rather than an email thread. Onboarding collects business details and documents, runs the checks you require and keeps the account in review until an administrator approves it. Listings and reviews can be moderated before or after publishing, with reasons recorded. A dispute or refund request opens a case both parties can see, with deadlines and evidence uploads, and the final decision adjusts the payment or payout automatically.

Yes, and that is usually the reason for building one. Each person belongs to an organisation, such as a customer account, a supplier or your own company, and holds a role within it, so permissions follow both who they work for and what they do. Each group gets its own interface on the same data: a customer portal, a supplier workspace and an operations console. One order or job record is shared, with each group seeing only the fields and actions relevant to it.

Most new platforms should start as a modular monolith: one deployable application with strict internal boundaries between modules such as accounts, orders, payments and reporting. It is simpler to build, test and operate, and it keeps a small team moving quickly. Because each module owns its data and exposes a defined interface, it can later become a separate service when its load, release rhythm or team justifies the move. Starting with many microservices adds network, deployment and monitoring overhead before the business model has settled.

We model each market as configuration attached to one codebase, so a new country is mostly setup rather than a copied system. A market record holds its currency, tax rates, languages, time zone, payment providers and any local approval rules. Amounts are stored with their currency to avoid conversion and rounding errors, and interfaces support English, Urdu and Arabic with right-to-left layouts. Where data residency matters, hosting regions are planned per market, which is far simpler to design in at the start than to retrofit.

Yes. We export and profile users, vendors, listings, orders and payment references from the current system, map them to the new data model and run trial migrations with reconciliation reports before the real one. Open orders and unpaid vendor balances are settled or carried across against a total that finance signs off. Existing passwords can sometimes be carried over safely; otherwise users receive a secure reset on first login. Old URLs are redirected to keep search traffic, and vendors can move across in groups.

Yes. We publish a documented API with separate credentials for each partner, so larger customers, suppliers or distributors can place orders, update stock or pull statements from their own ERP instead of using the portal by hand. Webhooks notify their systems when something changes, such as an order being dispatched or an invoice being raised. Each partner has its own rate limits and audit trail, plus a sandbox environment to test against before connecting to live data.

We choose one complete journey that proves the business model and build it end to end, rather than a thin version of every feature. For a marketplace that might be a vendor listing a service, a buyer booking and paying, and the platform paying the vendor out. For a partner portal it might be ordering and tracking. Anything that can be handled manually for the first users, such as rare admin tasks or advanced reports, waits for a later release.

A focused first release of a marketplace or partner portal is usually a matter of months rather than weeks. The timeline depends on the number of user groups, the complexity of payment and approval rules, the integrations required and how much data must be migrated. Because the first release covers one complete journey, it can reach real users while later groups, regions and modules are still being built, and you review working software every one to two weeks throughout.

Costs depend on scope, so we give a fixed quote for the first release after discovery rather than a figure up front. The main drivers are the number of user groups and interfaces, payment and payout complexity, integrations with existing systems, data migration, mobile apps and any regional or language requirements. We also estimate hosting and third-party running costs, such as payment fees and messaging, so you can see the full cost of operating the platform before committing to build it.

Yes, and we prepare for it in the first release by keeping data clean, structured and permissioned. Typical additions are matching buyers with suitable vendors, search that understands plain-language queries, extracting details from documents uploaded during onboarding and assistants that answer partner questions from your policies. Because they use the platform's access rules, an AI feature can only see and return records the current user is allowed to see. We add them where they remove a real manual step.