The Appsanic Principles: What We Believe About Building Software in the AI Era

Every company ends up with an implicit set of beliefs about its work. Most companies never write them down. We think that's a mistake. Written principles are a contract with future decisions. They remind you who you are when the next hard tradeoff shows up.

These are the ten principles that shape how we build Appsanic, what we say yes to, and what we say no to. They're not aspirational. They're the standard.

1. The user is not a developer

This one is first because everything else follows from it.

A user of Appsanic is someone with an idea and a willingness to launch it. They are not required to know React Native, TypeScript, Supabase, or Xcode. They are not required to read a diff. They are not required to debug a stack trace.

When we disagree internally about a feature, the first question is usually: does this feature require the user to be a developer? If yes, we redesign or don't release it.

There are places where we break this principle deliberately. If you want to edit the code by hand, you can. If you want to pair with Appsanic using your own GitHub workflow, you can. But the default experience never requires it.

2. The agent plans before it writes

We talk about this a lot because it matters that much.

A bad AI coding product types immediately. It feels responsive and produces code that has to be thrown away. A good one pauses, reasons, plans, considers, and only then writes.

Our agent takes between five and thirty seconds to plan before most non trivial work. Users who are new to the product sometimes worry this is a bug. We don't hide it. We think the pause is the feature. It's what separates an agent from autocomplete.

3. Real code, real ownership

Every Appsanic project produces a real React Native codebase in a real GitHub repo the user owns. Not a snapshot. Not a license. The code.

If the user cancels their subscription, the code stays. If Appsanic were to disappear tomorrow, the code still runs. The user's backend (Supabase project or equivalent) is in their account. Their app in the App Store is under their developer account.

Lock in is a strategy. We think it's a strategy that eventually fails, and a strategy that hurts users in the interim. We chose a different one.

4. Opinionated defaults beat endless options

A user who can choose between twelve button styles, eight color systems, five state managers, and three navigation libraries has been given a homework assignment, not a tool.

Appsanic picks. We use Expo. We use Supabase. We use Zustand. We use Tailwind style utility conventions. We use Sign in with Apple on iOS when required. We use EAS for builds. These are all reasonable defaults and we don't ask you to pick.

When a user needs something unusual, they can override. The override path exists. The default path is what launches 95 percent of apps.

5. Polish is not optional

An app that works is a prototype. An app that feels right is a product.

We hold the agent to polish standards that match what a senior engineer with taste would release. Empty states say something useful. Errors are helpful, not cryptic. Animations communicate, they don't decorate. Typography has a scale. Colors have meaning. Spacing breathes.

When we fail at this, we fix it. Polish is the difference between an app users return to and an app they try once.

6. Make it obvious what the agent is doing

We don't hide the work. The user can watch the plan. The user can watch the files being written. The user can see which connectors are being configured. When the agent makes a decision, it states the decision.

Transparency is not overhead. It's trust. Users who can see what the agent is doing learn to prompt it better. Users who can't see what the agent is doing have to trust it blindly, and blind trust is fragile.

7. Resist the urge to do more

The temptation of a capable agent is to let it do more things. "Can we also do web apps?" "Can we also do desktop?" "Can we also do games?"

We say no to most of these. Mobile apps are a huge market with specific needs. Going wide dilutes the specific things we do well.

The same discipline applies at the feature level. Every new feature is a new surface area, a new failure mode, and a new thing users have to learn. We say no by default. We say yes when the feature is the thing the user is asking for, not the thing we think they should want.

8. Small team, high standard

We keep the team small. Every engineer could be releasing production software on their own. Every hire is a high bar. Every decision can be made in a room that fits five people.

Small teams with high standards build faster than big teams with low standards, and the product stays coherent. We'll scale when we have to. We won't scale to feel bigger.

9. Be honest about the ceiling

Appsanic is not magic. It has specific strengths and specific weaknesses.

Strengths: mobile apps with standard architectures, SaaS companions, consumer utilities, B2B tools, small marketplaces.

Weaknesses: apps with hard realtime constraints, apps that need custom native modules we don't support, massively complex enterprise apps with years of accumulated logic.

We tell users which category their idea is in. If their idea is in the weakness category, we'd rather they go elsewhere than launch something bad with us. This has cost us customers. We think it's the right call.

10. Tell the truth

We don't lie in our marketing. We don't demo features that don't work. We don't quote customer testimonials we invented. We don't compare ourselves favorably to competitors by cherry picking.

When we claim "30 minutes from idea to App Store," we mean a specific, focused founder with a tight scope can hit that. When we claim "a real codebase," we mean it. When we claim "you own your code," we mean you own your code.

Marketing that overpromises is a short term gain that creates a long term trust debt. We try to leave the trust debt at zero.

The meta principle

Underneath these ten is one that ties them together: build the tool you'd want if you were the user.

Every decision at Appsanic is filtered through: would I use this? Would I respect the company that released this to me? Would I pay for this if I weren't building it?

When the answer is yes, we release it. When the answer is "maybe," we rework. When the answer is no, we throw it out.

The invitation, again

If these principles match how you think about building things, Appsanic will feel like home. If they don't, we're probably not the right tool for you, and that's okay.

Either way, we're not trying to be everything. We're trying to be specific. Everything in this list is specific. We intend to keep it that way.