Ten years of systems that shipped.
Consumer apps live on both stores, ecommerce platforms across four sectors, and the ERP systems that run manufacturing businesses. Most of this work sits under NDA, so it is described by sector and system type rather than by client name.
iOS & Android · community platform
Partaker & Enjoyer
A US church-technology company · Sole developer
Two consumer apps on iOS and Android for a client in Colorado — shipped, maintained and still in active development across multiple major versions.
Partaker serves Christian student clubs on university campuses; Enjoyer serves church congregations. They share a platform but differ in audience, content model and features.
These are not brochure apps. They handle payments, event registration and merchandise sales, stream a large audio and podcast library with offline playback, run a searchable member directory, and schedule reading plans that groups follow together. Content is managed by the client rather than hard-coded, so each club or congregation configures its own.
The relationship has run for years rather than months. Both apps went through a complete version 4 redesign in 2026 — rebuilt navigation, a rewritten media player, and new giving and registration flows — while remaining live for existing users throughout.
Both apps are public — click through and check.
- Platforms
- iOS and Android
- Status
- Live and actively maintained
- Latest major release
- Version 4, 2026
- Play Store rating
- 5.0 across both apps
What was built
- In-app payments, giving and merchandise sales
- Event registration and scheduling
- Audio and podcast player with offline playback
- Searchable member directory
- Client-configurable content and reading plans
- Group features with shared progress tracking
- App Store and Play Store release management
Selected client work
Delivered under NDA.
Client names are withheld. Sector and system type are not — you can judge the shape of the work, and we can talk about the specifics under an NDA of your own.
Ecommerce platforms
Four ecommerce builds across sectors with very different rules about who may buy what, at what price, and under what approval.
Dental supplies
A trade ecommerce platform selling to dental practices — professional catalogue, practice accounts and trade pricing rather than a consumer storefront.
Pharmaceutical distribution
Ordering for a pharmaceutical company, where product data, controlled categories and customer eligibility drive what each account is permitted to see and order.
Apparel and clothing
A consumer retail app with variant-heavy catalogue handling — size, colour and fit combinations that multiply quickly and break naive data models.
Bicycle manufacturing
A manufacturer’s customer-facing ordering app, built against the same ERP that runs their production and stock.
ERP and internal systems
The systems that actually run a business — less visible than a storefront, and considerably less forgiving when they are wrong.
Chemical manufacturing
An ERP and employee management system covering workforce records and internal operations for a chemical manufacturer.
Bicycle manufacturing
An ERP covering manufacturing operations, integrated with the customer ordering app above so stock and orders stayed consistent across both.
Asset management
Ongoing maintenance and defect resolution on an established iOS and iPad application for an asset management firm — inherited code, kept stable and shipping.
Consumer and real-time apps
Products where responsiveness and delivery guarantees are the product, not a detail.
Messaging and polling
A real-time messaging application with group conversations and live polling — message delivery, ordering and state synchronisation across devices.
News
A news application with continuously updating content, feed handling and push notification delivery.
How this connects to the AI work
Nothing above is an AI project, and it would be dishonest to imply otherwise. It is worth explaining why we think it is the relevant experience anyway.
The hard part of putting an AI agent into production is rarely the model. It is the system around it: integrating with an ERP that was not designed to be integrated with, deciding what an agent is permitted to do and enforcing it, handling the third party that times out, keeping state consistent when something fails halfway, and knowing what to log so a failure can be diagnosed at 3am rather than guessed at.
That is ordinary backend engineering, and it is what the last decade of this work has been. An agent that writes to your order system has the same failure modes as an ecommerce app that writes to your order system — plus a model that is sometimes wrong, which is why the evaluation and approval layers exist.
Want the detail we cannot publish?
We will walk through architecture, decisions and what went wrong on a call — under an NDA if you would prefer.