We’ve been building Nomii, a family memory keepsake app for parents, for a while now. How we build it has changed a lot in that time. We started in a low-code app builder. These days it’s React Native in a repo we own, with Cursor and a pile of AI tools doing most of the typing.
It wasn’t a dramatic break, more a gradual shift. The product got clearer, our needs got more specific, and the tooling around us caught up to the point where the next step felt natural instead of risky.
Why a builder was the right place to start
Nomii isn’t a project we can give forty hours a week. It’s something we build in the gaps: evenings, weekends, the occasional stolen hour between day jobs. At that stage, low-code made a lot of sense.
Draftbit gave us a visual way to lay out screens, wire up navigation, and iterate on UI without bootstrapping a full React Native project from scratch. For a small team with mobile experience in the room but no one living in that world day to day, that’s a reasonable trade. We weren’t avoiding code so much as avoiding setup, while we figured out what Nomii actually was.
And it worked. The first version came together faster than we expected — screens, flows, basic data wiring, all the stuff that usually eats the first week of a mobile project. Draftbit let us focus on the product idea: how parents capture milestones, stories, voice recordings, and the bits of family life that scatter across camera rolls and group chats.
That early phase is exactly what a builder is good for. Get something in front of people, learn, move on.
When the project started asking for more
As Nomii grew, so did the gap between what we wanted to build and what felt comfortable inside the builder.
The product vision got more specific: richer memory types, templates and prompts, multi-user accounts, a legacy access system we’re designing for the long term. The flows got more interconnected too. The UI stopped being a collection of screens and started being a system, with navigation, state, and media handling that needed to evolve together.
Around the same time, a few things shifted in our toolchain. Expo had matured to the point where the old mobile setup tax (Xcode rabbit holes, SDK path drama, an evening lost to pod install) was mostly gone. Cursor and AI coding agents had gone from novelty to something we were already using seriously on other projects. pen.dev gave us a way to bring our existing Figma designs into Cursor as implementation artifacts, which was basically the visual handoff we liked about the builder, minus staying inside one.
Draftbit’s move to v2 was part of that picture too, a reminder that the platform was heading in a different direction, with more emphasis on AI assistance and less on the no-code workflow we’d built the early Nomii prototype in. It wasn’t some villain origin story, it just sharpened a question we’d already been circling: are we still in the phase where a builder is the best fit, or have we moved past it?
We had.
Expo made the switch feel possible
The thing that kept us on a builder longest wasn’t fear of React Native. It was the feedback loop.
We needed to change something, see it on a phone, show it to the rest of the team, and keep going, without a build pipeline getting in the way.
Expo flattened a lot of that. One project template, a dev server, a QR code on your phone, and you’re looking at the app in minutes. Hot reload. Over-the-air updates when we need them. A testing loop that matches how we actually work on Nomii now: implement, run in Expo Go, test on a device, iterate.
That’s what made the switch possible. The setup cost we’d been paying the builder to absorb was suddenly cheap enough to carry ourselves, especially with AI handling a fair chunk of the boilerplate.
Cursor, agents, and owning the codebase
Moving off the builder didn’t mean going back to hand-coding every screen like it was 2017. The whole point was still speed. We just wanted speed with source code we could read, diff, refactor, and grow as Nomii gets more ambitious.
Cursor is where Nomii gets built now. Same pattern we use on other projects: an AGENTS.md with conventions, clear scope boundaries, and enough context that the agent isn’t guessing at architecture every session.
In practice that looks like:
- Describing a screen or flow in plain language, then iterating on the generated React Native components
- Using the agent for the tedious glue (navigation wiring, form validation, API client scaffolding) while we stay in the director’s seat on product decisions
- Fixing the subtle misses in review: state that works on the happy path but breaks on back navigation, accessibility gaps, the UI that’s technically correct but not quite Nomii
The output lives in our repo. We can run it locally, test it in Expo Go, rip out a component that isn’t working, and prompt our way to a better version. As the product gets more complex, that ownership matters more. Builders aren’t bad, they just don’t give you a home you control, and mature products tend to need one.
From Figma to code via pen.dev
We were already designing Nomii in Figma. That’s where the team iterates on layout, flow, and visual polish. What we didn’t have was a clean way to get those designs in front of Cursor as something the agent could actually work from.
Describing UI in prose works fine for simple screens. For anything with real visual intent (spacing, hierarchy, component structure) it turns into a game of telephone. You end up reviewing generated code that sort of matches the design, then spending as long fixing it as you would have spent just building it.
pen.dev bridged that gap. We drop Figma designs in as artifacts alongside the prompt, and Cursor uses them as reference during implementation. The agent isn’t guessing at what “the memory capture screen” should look like; it can see the design we already agreed on.
The workflow is design in Figma, reference in Pencil, implement in Cursor, run in Expo, test on a device. Each step has a clear handoff. We’re not asking the AI to be a designer and a developer at the same time — we’re giving it the same brief a human developer would get.
What changed, and what didn’t
Different tools, different tradeoffs — not a strict upgrade in every dimension.
We took on more responsibility. Responsive layouts, component libraries, navigation patterns, media handling — the builder had been absorbing some of that thinking for us. Going native-ish means we own those problems again, which is more work but also more flexibility as Nomii’s feature set grows.
There’s a learning curve to prompting well. A builder UI is constrained; you can only do what the widgets allow, which is frustrating but also guard-railed. Cursor will happily build exactly what you asked for, including the parts you forgot to mention. Review becomes part of the craft.
And cost isn’t zero: Cursor subscription, Expo tooling, our time reviewing generated code. But it’s a cost structure that fits where Nomii is now — pay for tools, own the output, no platform ceiling on what we can build next.
What we’d tell ourselves at the start
If we were starting from scratch today, knowing what we know now, we’d probably still begin with a builder, or at least something equally fast and visual, and plan to graduate once the product vision solidified. That early phase was worth it. We didn’t waste time wrestling a toolchain; we spent it learning what parents actually need from a memory keepsake app.
We’d just write the AGENTS.md earlier when the switch happened. The first week of agent-assisted development involved a lot of re-explaining conventions that should have been captured once. Same lesson as every other AI-native project we’ve worked on: the context doc is the product.
Where Nomii is now
Nomii is still very much in progress — we’re on the waitlist phase while we build out the app. But the build loop feels right for this stage: fast iteration on real devices, a codebase that can grow with the product, and AI doing the parts of mobile development we were happy to delegate anyway.
Draftbit got us moving when speed mattered most. Expo, Cursor, and Pencil are how we build now that Nomii knows what it wants to be.
We’ll write more about Nomii itself as we get closer to launch. For now, we’re just enjoying building a mobile app with agents, on our terms, in a repo that’s finally ours.