Engineering case study
Domainerly.
Native iOS + AI.
A domain suggestion is only the beginning. Domainerly connects an open-ended naming brief to structured ideas, availability checks, and a shortlist worth returning to.
The problem
Naming combines a creative problem with a changing external fact: whether a domain is available. Those two jobs need different feedback, different failure states, and a clear handoff.
The architecture
SwiftUI presents the product while dedicated services handle generation, model selection, authentication, and domain lookups. A Cloudflare Worker provides the server boundary for AI requests. Firebase supports account services, and RevenueCat handles subscription entitlements.
Decisions that shape the product
Separate suggestions from facts.
AI-generated names do not become availability claims. A dedicated availability store records the lookup result, source, and check time, and can represent an unknown result.
Keep a shortlist coherent.
Domain and folder models give saved ideas a durable structure. Shared availability state lets different views display the same recent check instead of competing answers.
Design for an imperfect network.
Generation responses are decoded into typed suggestions. Network failures and unavailable providers remain explicit states the interface can handle.
How the parts connect
- 01BriefDescribe a name and its constraints
- 02GenerateA server-mediated AI request
- 03CheckIndependent availability state
- 04OrganizeSave domains into folders
Engineering focusNative product architecture · Structured AI output · External API state · Subscription integration
Visit Domainerly