A digital invitation platform, from proof-of-concept skeleton to public release

Context

The client’s product is a mobile app for digital invitations: users pick from a categorised template library, personalise it, send it to contacts from their address book, then track deliveries and opens.

A seven-person team — two mobile developers, two designers, a project manager and the product owner, with the backend owned entirely by us.

Problem

When we joined, the backend existed only as a proof-of-concept Laravel skeleton: no domain boundaries, no static analysis, no linting. The mandate was to turn it into a production-ready API for the mobile clients against a fixed scope and timeline, as the project’s only backend development resource.

A second problem was quieter but expensive: designers produced templates in Figma and handed assets over manually, and the mobile team faced implementing a rich canvas editor twice — once on iOS, once on Android.

Approach

Structure first

We restructured the proof-of-concept codebase around Domain-Driven Design, establishing clear domain boundaries in place of an ad-hoc skeleton, and refactored the existing implementation to production standards. Linting and static analysis went in as automated quality gates on a codebase that had neither.

Then the core REST API consumed by the mobile applications, documented with OpenAPI.

One editor, not two

The API exposed the categorised template library. Once a user selected a template, the mobile app opened a webview hosting a canvas editor built on Fabric.js — direct manipulation of the invitation, text entry, font selection, colour and alignment — saving the finished design back through the API.

That let a small mobile team ship a rich editing experience without building native canvas editors on both platforms.

Design straight into production

A Figma API integration pulled the designers’ finished blank templates and their fonts directly into the platform and exposed them to the editor, removing manual asset hand-off entirely.

Delivery and access control

Each recipient’s email carries a link with a unique per-recipient code. Opening it both registers the open event for the sender’s analytics and renders the invitation — and because the code is recipient-scoped, nobody else can access that invitation. Per a product decision, each code expires after three views. A bulk send pipeline handled large recipient lists drawn from the user’s contacts.

Passwordless OTP authentication over an SMS provider removed password management entirely.

Monetisation metered at the unit of cost

Rather than a payment gateway, the platform monetised through Apple in-app purchase packages: users bought tiered token bundles through the App Store, and the platform maintained a token-based credit ledger where each send was costed by recipient count and debited against the balance — metering usage at the exact unit driving platform cost.

Outcome

• Delivered the complete agreed scope and took the product to public release, handing over a production-ready backend the client continued to develop in-house.
• Took the backend from proof-of-concept skeleton to production system outright, introducing domain-driven structure, static analysis and linting where no engineering standards had existed.
• Built a fully automated design-to-delivery pipeline — Figma templates ingested by API, edited by users in a canvas editor, distributed through per-recipient access-controlled links, with open tracking feeding back to the sender.