Build or buy a customer self-service portal

A small business-to-business software company decides whether to build a customer portal, licence one, licence and extend one, or defer. The log shows a contractual renewal date doing the work of elim...

Published content

1. node: Context. The organisation is a business-to-business software company of approximately 60 staff, with four engineers, selling a subscription product to enterprise customers in the United Kingdom and the European Union. Customers currently obtain invoices and user administration by emailing the account team. Three enterprise customers have asked for self-service access to invoices and user administration, with single sign-on through their own identity providers.
2. node: Should the organisation build a customer self-service portal, licence one from a vendor, licence and extend one, or defer the decision?
3. node: Estimate. The engineering team sized the three requested capabilities at 200 engineer-days: invoice access, user administration and single sign-on.
4. node: Evidence. The vendor quoted an annual licence for the organisation's seat count with invoice access, user administration and single sign-on included in the base tier, and a standard data export on termination.
5. node: Evidence. The vendor's interface covers all three requested capabilities, so the customer-facing presentation can be the organisation's own while the underlying service remains the vendor's.
6. node: Decision-maker. The Chief Technology Officer, under the delegated authority for technology commitments below 100,000 euro of first-year cost. The recommendation is put to the management team meeting of 24 June 2026.
7. node: Risk. Deferral misses the January renewal date under every option that could follow it. One renewal carries self-service access as a condition, so the cost of this option is a renewal placed at risk rather than a saving.
8. node: Scope. The decision covers how the portal is obtained and who operates it. It does not cover the scope of the portal beyond the three capabilities customers have asked for, nor the pricing of the subscription product, both of which are settled elsewhere and treated here as fixed.
9. node: Evidence. The portal would run on the organisation's existing authentication and data model, so no customer personal data would leave the current processing arrangements and no new sub-processor authorisation would be needed.
10. node: Evidence. Two reference customers of comparable size were live within seven weeks, and neither required engineering attention after the first month of operation.
11. node: Rationale. Deferral would allow the billing migration to complete before any competing demand on engineering capacity, removing the dependency that makes the build estimate uncertain.
12. node: Consulted. The Data Protection Officer on the sub-processor position, the account team on customer expectations, and the engineering team on the build estimate and its dependency on the billing migration. The account team recorded a preference for building on branding grounds.
13. node: Risk. Two of the three reference customers the vendor provided for extended deployments had extensions break on a vendor upgrade, one losing approximately three weeks to recovery. That cost recurs on the vendor's release schedule rather than the organisation's, and is the reason the five-year cost of this option is recorded as unknown rather than estimated.
14. node: Constraint. Two of the four engineers are committed to a billing system migration until October 2026. Any option requiring substantial internal build competes directly with that programme for the same people.
15. node: Risk. The 26-week estimate assumes engineering capacity is released in October and that all four engineers then work on the portal. The billing migration has already slipped twice; a third slip, or any call on the engineers from the existing product, places launch beyond the January renewal date, which is the one deadline with a contract attached to it.
16. node: Risk. Branding is limited to a logo and a colour pair. For the enterprise customers who requested this, the portal is the visible face of the product to their own staff.
17. node: Risk. This option carries the compliance obligations of buying and a substantial part of the maintenance burden of building, without the full control of either.
18. node: Rejected options. Building is estimated to cost less over five years, but it reaches the January renewal only if the billing migration does not slip again and all four engineers move to the portal in October. Licensing and extending adds sixty days of work and recurring upgrade breakage for branding the account team values but no customer has made a condition. Deferral misses the renewal under every later choice.
19. node: Action. Seek prior written sub-processor authorisation from the customer whose agreement requires it, notify all other customers of the new sub-processor under their general authorisation terms and allow the objection period their agreements set, and put a data processing agreement in place with the vendor, before any customer data is transferred. Launch is conditional on all three.
20. node: Constraint. One of the three enterprise customers has made self-service invoice access a condition of its renewal, which falls due in January 2027. That date is contractual rather than aspirational and bounds every option.
21. node: Risk. Building commits the organisation to operating a customer-facing service it has never operated before, at an ongoing effort figure that is an estimate rather than an observation.
22. node: Risk. Engaging a new sub-processor requires prior authorisation from at least one customer whose agreement restricts it. If that authorisation is refused or delayed, the option cannot launch on time and the advantage over building disappears.
23. node: Action. Instrument the portal from launch to record which capabilities are used and how often, so that a later build decision rests on observed use rather than on the three capabilities customers thought to ask for.
24. node: Constraint. The same customer's data processing agreement requires prior written authorisation before any new sub-processor is engaged. Any option placing customer data with a vendor requires that authorisation to be sought and granted before launch.
25. node: Regulation. Article 28 of the UK GDPR, and of the EU GDPR in the same terms, provides that a processor shall not engage another processor without prior specific or general written authorisation of the controller, and that where general authorisation is given the processor must inform the controller of intended changes so that the controller may object. Where a sub-processor fails to meet its data protection obligations, the initial processor remains fully liable to the controller.
26. node: Review trigger. If sub-processor authorisation is refused or is not granted by 31 October 2026, this decision is void and the build option is reconsidered immediately, on the basis that January will likely be missed and the renewal condition must be renegotiated with the customer.
27. node: Official guidance. The Information Commissioner's Office sets out what a controller-processor contract must contain, including the requirement that the processor only engages a sub-processor with the controller's prior authorisation and imposes the same data protection terms on it. This is the basis for treating sub-processor engagement as a gating step rather than a post-launch administrative task.
28. node: Review trigger. Review in March 2028 against recorded usage. If customers are using materially more than the three requested capabilities, or if licence escalation has moved the five-year position, reconsider building.
29. node: Assumption. The loaded cost of an engineer-day is 480 euro. All build and effort figures below are derived from that rate; if it is materially wrong, the ranking of the two build-inclusive options against the licence-only option changes.
30. node: Assumption. Customer demand stops at the three capabilities requested. No option has been sized for a wider portal, and the five-year cost figures assume no significant scope growth. This assumption is the one most likely to fail.
31. node: Build the portal in-house
32. node: Licence a portal from a vendor and use it unmodified
33. node: Licence a portal and extend it through the vendor's interface
34. node: Defer the decision to December 2026
35. node: Recommendation. Licence the portal from the vendor and use it unmodified, subject to sub-processor authorisation being obtained before launch. The January renewal date is contractual and only the two licence-based options reach it with margin. The recommendation accepts a higher estimated five-year cost than building (about 214,000 against 174,000 euro), weak branding and no roadmap control for an initial term, in exchange for meeting a contractual commitment and learning which capabilities customers actually use before committing 96,000 euro to building them.