What We Build, and How

Native iOS in Swift and SwiftUI when the app should feel like it belongs on the platform. Flutter when one codebase across iOS and Android is worth more than the last 5% of native polish. Capacitor with Ionic and Vue when there's already a web application and the mobile app needs to share its logic rather than reimplement it. We've shipped production apps on all three, which is the only honest basis for recommending one over another.

The build is the part everyone plans for. These are the parts that actually slip, and we handle them:

• App Store review. Submission, the privacy label declarations, the metadata, and the response when it comes back rejected for a reason that isn't in the guidelines you read.
• Purchases and subscriptions. In-app purchase infrastructure, receipt validation, restore flows, family sharing, trials, and the entitlement edge cases that only appear when a real customer is offline in a different region.
• Platform capabilities. Push and local notifications, widgets, Live Activities, Siri and App Intents, Control Center entries, background execution, and permission flows that don't get denied on first launch.
• The long tail. Accessibility with real VoiceOver labels, iPad and landscape layouts, Dynamic Type, offline states, and the annual iOS release that changes something you depended on.

Shipped examples you can download: Rouse uses AlarmKit for system-level alarm scheduling plus HealthKit, Live Activities, and widgets. Pentire runs an on-device image segmentation pipeline built on Apple's Vision framework. Chat Local implements a custom binary protocol over Bluetooth Low Energy with mesh relay. CalcBoard is Flutter, with an arbitrary-precision decimal engine and a Pratt parser behind it.

Two quite different jobs that often get bundled together, so we price and plan them separately.

Web platforms are the ones with real infrastructure behind them: user accounts and authentication, payment processing, search over content that keeps growing, secure delivery of files that shouldn't be shareable, and an admin surface someone non-technical has to operate every day. We built and ran My EDU Marketplace end to end — a marketplace where educators sold lesson plans and study guides, with Stripe payments, secure digital delivery, full-text search, and authentication — so this is a system we've operated, not just assembled.

Marketing sites are a different discipline: fast, static where possible, and built to be found. That increasingly means two audiences. Search engines still want clean information architecture, correct structured data, real page speed, and pages that match a query rather than mirroring your org chart. AI assistants now answer in front of those results, and they reward something else — direct-answer content, consistent entity naming across every property you own, claims that don't contradict your other sources, and machine-readable summaries.

This site is the worked example. Every app we publish has its own marketing site with structured data, FAQ markup, an llms.txt corpus, and landing pages built against real queries. You can read our own llms.txt to see the shape of it.

The least glamorous category and usually the highest return per dollar, because the return is measurable before you start: someone is spending four hours a week moving data between two systems, and after the project they aren't.

• Workflow automation — the recurring manual process that exists because two tools don't talk, or because a report has to be assembled by hand every Monday.
• Database design and repair — schema work for something being built, or untangling a schema that grew organically and now makes every query slow and every new feature expensive.
• Integrations — connecting systems that were never designed to be connected, including the ones with hostile or undocumented APIs.
• Internal tools — the small purpose-built interface that replaces a shared spreadsheet with a locking convention and one person who understands it.
• Data migration — moving off a platform you've outgrown, with the reconciliation step that proves nothing was lost.

These projects are usually the fastest to scope, because the current cost is already known. If you can tell us how many hours a week the manual version takes, we can tell you fairly quickly whether automating it is worth doing.

Engagements where the deliverable is a decision and a written recommendation, not a codebase. Often cheaper than the mistake it prevents.

• Architecture review — a second opinion on a design before it's built, or on a system that's already creaking, with specifics rather than a maturity score.
• Build versus buy — whether the thing you're about to commission already exists as a product you could subscribe to for a fraction of the cost. Sometimes it does, and we'll say so.
• Platform and stack selection — native versus cross-platform, which framework, which services, and what each choice costs you in two years rather than this quarter.
• App Store and privacy compliance — privacy label declarations, App Tracking Transparency, data-collection disclosures, and the review guidelines that are easy to trip over.
• Stalled project assessment — an honest read on whether to continue, refactor, or restart, and what the remaining work actually is. This is often the most valuable and least comfortable conversation on the list.
• Technical due diligence — evaluating a codebase you're considering acquiring, inheriting, or taking responsibility for.

The stack, and where it's running

Everything below is in production in an app you can download today, which is a stricter test than a capabilities list. Where we haven't shipped something, it isn't here.

Swipe the table sideways to see every column.

Not on this list, deliberately: Android native, backend languages we haven't shipped, and anything we'd be learning on your budget. If a project needs one of those we'll tell you rather than quote for it.

How engagements work

1. A free scoping call. You describe the problem. We ask about the constraints that usually get discovered late — who has to operate this, what it integrates with, what happens to the data, what the real deadline is driven by. You leave with a view on what we'd build and where the risk sits, whether or not you hire us.

2. A written scope, before any code. What's being built, what explicitly isn't, the schedule, the price, and what we need from you and when. The non-goals section is the important one: projects overrun because the boundary was never written down, not because anyone was slow.

3. Working software, early and often. Progress is demonstrated as builds you can install and use. For mobile work that means TestFlight from early on, because an opinion about a running app is worth ten about a mockup. You'll see it while it's still cheap to change your mind.

4. Launch, and a handover you can act on. App Store submission and review correspondence, or production deployment. You get the source, the accounts in your own name, and documentation written for whoever maintains it next — explicitly including the case where that isn't us.

5. Maintenance, optional. Mobile especially needs it: every annual iOS release can deprecate something you relied on. That can be an ongoing arrangement or occasional scoped work, and it's never a condition of the original project.

On pricing

We don't publish a rate card, because a number quoted before scoping is a guess wearing a suit. What we will commit to: after the free scoping call you get a fixed price or a capped estimate in writing, and the number you approve is the number you pay unless the scope changes — in which case you approve that in writing too. No hourly meter running quietly in the background.

What we turn down

Saying this out loud saves everyone a call:

• Products whose business model depends on dark patterns or ads that misrepresent what's inside. We built a whole game satirising the first one.
• Work needing deep platform expertise we don't have. We'd be learning on your budget, and you'd be paying for the education.
• A deadline the scope can't fit. We'll propose a smaller scope that does fit; if that's refused, it's better to decline than to miss it together.
• Engagements where nobody on your side can make a decision. That one is fatal regardless of who builds it.