Skip to content
cirlume.
Menu
← All expertise

Expertise / 02 of 04

Software engineering.

Build connected web and mobile products, with the APIs, data and permissions behind the screens.

Tell us what you’re building
A laptop showing a code editor beside a phone and tablet running the same app layout, with a coral USB-C cable

When to bring us in

Sound familiar?

  • You are building a new platform, or one has outgrown its first version.
  • Customers and staff need web and mobile apps that share the same data.
  • Manual handoffs between tools are slowing everyday work.

Why us

What we bring to software engineering.

  • We run what we ship

    We build and operate SoulCare and SimRhythm ourselves, so releases, support and upgrades after launch are familiar work.

  • One codebase where it fits

    SimRhythm runs on iOS, Android and the web from a single Expo app, which keeps three platforms on one release.

  • Code and accounts in your name

    Repositories, cloud accounts and databases belong to you, and handover includes deployment steps and operating notes.

Benefits

What changes for you.

Illustration for software engineering

  • One version of the record

    Customers, staff and administrators work from the same data, so nobody re-keys a record from one system into another.

  • Changes you can ship

    Tests on the paths that must not break let your team change the product without wondering what else moved.

  • Access that matches roles

    Each person sees and does only what their role allows, which makes access reviews and audits simpler to answer.

  • Code your team can own

    Readable structure and recorded decisions mean another developer can pick the work up without starting over.

Capabilities

Start with the part you need.

What the work includes

Build the whole journey, not just the visible screen.

Customer experiences, staff tools and administration often depend on the same underlying data. We design the boundaries between them, build the APIs and interfaces together, and check the critical paths as working software.

  1. Web & mobile applications

    Customer apps, staff tools and admin screens built as one product on shared data.

  2. APIs & integrations

    Connect the product to the systems your team already relies on, with clear contracts between them.

  3. Architecture & quality

    Data boundaries, permissions and tests for the paths that must not break.

Use cases

Projects we take on.

Where AI helps

Useful, on a short leash.

Bounded jobs a model can take on inside software engineering work, with a person checking the result.

Where it stops: permissions, releases and decisions that matter stay with ordinary tested code and a named person, not a model’s output.

A practical sequence

How the work runs.

  1. Map the system

    Identify roles, data, existing services, integration points and the smallest coherent release.

  2. Build connected slices

    Deliver reviewable end-to-end journeys rather than isolated screens or backend components.

  3. Check real conditions

    Test permissions, failures, edge states and deployment before preparing a handover.

Tell us what you’re building ↗

Relevant product work

See it in practice.

Medical education / Our product

SimRhythm

SimRhythm keeps ECG and capnography on one monitor clock beside its simulator controls, in a single app for iOS, Android and the web.

Explore SimRhythm ↗
SimRhythm training monitor showing ECG and capnography traces, vital signs, and defibrillator controls
SimRhythm / Training monitor · Product interface

Industries

Software engineering by sector.

What’s changing

Shifts to plan for.

Dates that affect software engineering work, checked against the official sources.

  1. August 2026

    Google Play targets Android 16

    New apps and updates for phones and tablets must target API level 36. Extensions can be requested until 1 November 2026.

  2. April 2026

    Node.js 20 reaches end of life

    The Node.js project stopped security fixes for version 20 on 30 April 2026, so services still on it need a move to 22 or 24.

  3. April 2026

    App Store requires the iOS 26 SDK

    Since 28 April 2026, uploads must be built with Xcode 26. Apps can still support older iOS versions; only the build tools changed.

Technologies we use

Tools chosen for the product.

Web
React
Next.js
Astro
Tailwind CSS
TypeScript
Back end
Node.js
Go
Python
Firebase
Supabase
Better Auth
Mobile
React Native & Expo
Flutter
Swift & Kotlin
Data
PostgreSQL
MySQL
Cloud & infrastructure
AWS
Microsoft Azure

Cost

What shapes the estimate.

  • Platforms in scope

    A web app alone is smaller than web plus iOS and Android, even when one shared codebase covers more than one platform.

  • Systems to connect

    Every external system adds work. One with thin documentation or no API at all adds considerably more.

  • Data migration

    Moving records from an old system means cleaning, mapping and checking them, and older data is rarely as tidy as expected.

  • Decisions still open

    Unsettled questions about roles, rules or workflows resurface during the build, where they are slower and dearer to resolve.

Engagement

Ways to work together.

  1. A first, fixed stage

    Discovery, a prototype or a technical review with agreed outputs, so the next decision is made with something concrete in hand.

  2. Delivery in phases

    The build split into releases, each with a scope you review and approve before it starts.

  3. Ongoing engineering

    An agreed scope for support and improvements after launch, with response expectations written down.

Tell us what you’re building ↗

Choosing a partner

Questions to ask any provider.

Including us. The answers tell you more than a portfolio does.

  1. Who owns the code and the accounts?

    You should hold the repositories, cloud accounts and app store listings, so changing provider never means losing access.

  2. How do you test the parts that matter most?

    A general promise of good testing tells you little. Ask which paths are covered and how failures are caught before release.

  3. How will we see progress?

    Working software you can try at regular points shows real progress. Status reports on their own can hide a problem for weeks.

  4. What happens if another team takes over?

    Documentation, readable code and a defined handover decide whether a new team can continue the work or has to start again.

Common questions

Before you get in touch.

Can you work on an existing codebase?

Yes. We start by reviewing the architecture, dependencies, deployment and the area you want to change. That review helps us scope work around the system you already have.

Can you collaborate with our internal developers?

Yes. We can agree a defined part of the product, shared interfaces and a review process with your team. Responsibilities and handover expectations are part of the scope.

Which technologies do you use?

Our work includes React, Astro, React Native with Expo, Go, Node.js, PostgreSQL, AWS and Terraform. We choose around the product, existing systems and the team that will maintain it.

How long will a build take?

That depends on scope, integrations, data migration and the decisions still to be made. We estimate after understanding those dependencies and can separate the work into releases.