Representative web and mobile builds from our studio

The client ran a services booking business on a website that had grown into something its original developer no longer maintained. Bookings were handled by a form that emailed someone, who then entered it into a calendar manually. We rebuilt the booking flow as a Next.js application with server-side rendering, a proper availability model and an admin view for the staff who had been doing the manual work.

Situation

A booking business running on an unmaintained site and a manual calendar entry.

Stack

Next.js with server-side rendering, an explicit availability model, and a staff admin view.

Changed

Staff stopped re-entering bookings; the informal scheduling rules they applied by hand moved into code.

A two-person team wanted to test whether a niche marketplace had demand before raising money. We built the first version on Bubble, since a visual platform with a built-in database and workflows covers validation extremely well and gets to first users fast. Payments and messaging were deliberately manual at the start. When listings and transactions proved the model, we rebuilt the parts that needed to scale, kept the data model and behaviour we'd learned, and migrated.

Situation

A two-person team testing demand for a niche marketplace before raising money.

Stack

Bubble first for validation, then a code rebuild of the parts that needed to scale.

Changed

The MVP answered the question cheaply — no wasted build on an unproven model.

A facilities company had staff logging job completion on paper, then handing it to an office administrator to type up. We built a cross-platform mobile app with one codebase serving iOS and Android, offline-first, with photo capture attached to each job record. Offline behaviour was the bulk of the engineering, not the screens. The app syncs when signal returns, so a job logged in a basement doesn't vanish.

Situation

Paper job logs handed to an office administrator to re-type into an office system.

Stack

One cross-platform codebase for iOS and Android, offline-first, photo capture per job.

Changed

Jobs logged in a basement sync when signal returns; admin re-typing left the process.

A product team had a working iOS app and a growing Android requirement, with no appetite for maintaining two full codebases. We moved shared business logic into Kotlin Multiplatform while each platform kept its native UI. It's a gradual approach by design, and that suited them: no big-bang rewrite, no lost month.

Situation

A working iOS app, a growing Android requirement, and no appetite for two full codebases.

Stack

Kotlin Multiplatform for shared business logic, native UI retained per platform.

Changed

Shared logic where it made sense, native UI where it mattered, no lost launch window.

Caveat: the middle path between pure native and full cross-platform UI is right for teams in this position, but it does assume Kotlin familiarity on the team or a budget to build it.

An operations team ran a key process through a shared workbook that had grown to sixteen tabs and broke roughly weekly. We replaced it with an API-first web application: a Postgres backend, a defined API contract, and a frontend built on components so new views didn't mean new styles. The contract came first, which meant we could build and test the backend independently.

Situation

A key operational process running through a sixteen-tab shared workbook.

Stack

Postgres backend, a defined API contract, and a componentised frontend.

Changed

The spreadsheet left the process; new views stopped meaning new styles.

A client came to us with an app that worked but shipped nervously. Testing happened in the final week, on whichever devices were nearby, and releases regularly needed a follow-up patch. We didn't touch the feature set. We introduced automated UI tests with Maestro for the critical flows, established a device matrix tied to their actual user base, and wrote a short release checklist including a tested rollback.

Situation

A working app that shipped nervously, tested in the final week on nearby devices.

Approach

Maestro UI tests for critical flows, a real device matrix, and a short release checklist with a tested rollback.

Changed

Release anxiety dropped because the process stopped depending on individual memory.

A professional services firm needed a client portal where documents moved between parties with a clear audit trail. The constraints drove the architecture more than the features did: retention rules, access logging and a defined approval step before anything was shared. We built an API-first web application with the audit model designed before the interface.

Situation

A professional services firm needing a client portal with a defensible audit trail.

Stack

API-first web application; audit model designed before the interface.

Changed

Retention, access logging and the approval step became architectural facts rather than a later rebuild.

One client wanted to explore voice as an input method for a hands-busy workflow. We built a browser-based prototype quickly using a cloud development environment to test the interaction before committing to an app build. It's a good example of using fast tooling for what it's good at: answering a design question cheaply.

Situation

A hands-busy workflow, and a client asking whether voice was a useful input at all.

Approach

A browser-based prototype built quickly in a cloud development environment.

Changed

The prototype answered the design question before any app build commitment.