Rapid prototyping and AI development for a startup: from idea to a mobile app in 1 week

Attico’s team developed a mobile app for healthy eating in just a week using AI for rapid prototyping.

Sep 28, 2026 15 min read

Rapid prototyping and AI development for a startup

Introduction

AI is becoming a regular business tool, especially for large companies. The U.S. Census Bureau reports that 37% of companies with 250+ employees are using AI in 2026. In the Information sector, the number is close to 40%.

At this point, the question is no longer whether to use AI in business workflows. It’s about how to bring AI into everyday work without letting speed come at the cost of quality or creating more technical debt.

You can see this clearly when starting a new product. Requirements are constantly changing, some decisions have to be made along the way, and the result is needed quickly.

Asking an AI agent to “build the app” isn’t enough in this situation — for complex products, it’s important to define clear rules upfront, agree on the requirements, and leave less room for interpretation.

That’s exactly what we at Attico wanted to test in practice — using AI for rapid prototyping to build a working proof of concept for a mobile app in a short time, with designs for about half of the screens, high-level requirements, and two ready-to-use APIs.

The idea came from our partner, who suggested working together and sharing our knowledge and ideas. From our side, we could bring in our technical expertise and focus on the areas we know best.

At first, we took the usual approach. We used some of our existing work and reusable components — our design system, prototypes, the client’s color options, and our existing solutions for web and mobile apps.

But it quickly became clear that this wasn’t enough for a proof of concept (PoC). The product idea was still taking shape and could change a lot as we worked on it.

So we decided to try a different approach. We moved to AI-assisted development and then based our work on specification-driven development (SDD), which we’ll explain below.

Choosing the tech stack and AI tools

Our team chose the tech stack with one thing in mind — most of the development would be done by an AI agent.

That’s why we went with React Native — a popular technology with a large ecosystem, extensive documentation, and many real-world use cases, so this made it easier for the AI agent to work with the technology.

We also used Expo, which provides tools and services for React Native, including the SDK, development tools, and services for building and delivering apps. In our project, it helped us work with libraries and build the final app.

In the end, React Native + Expo was the most practical and easy-to-understand setup for this kind of PoC.

For the AI tools, our specialists naturally used Claude Design, Claude Code, and SpecKit toolkit together.

We had already used Claude Design for designs, templates, and prototypes, so it made sense to keep using it for this experiment. Claude Code was chosen to work alongside Claude Design because they are part of the same ecosystem. We also added SpecKit, an open-source toolkit for applying the SDD approach. It helps the AI agent create and follow a clear specification, and it integrates easily with Claude Code.

Project starting point

At the beginning, our team had a fairly basic setup: an idea from the client, examples of similar apps, designs for about half of the screens, and high-level requirements that were still changing as we worked. We needed to build two ready-to-use APIs — one for authentication and user data, and another for integrating with the AI system.

The application — a healthy eating service — was built completely from scratch using AI for mobile app development. Via this app, users could sign up, get AI-powered recommendations about healthy food, and track their data.

SDD and why it matters in AI development

SDD — Spec-Driven Development — is an approach where the specification is written first, and the application is built based on it.

In the past, a developer would get a document from a business analyst or project manager explaining how the system should work and then build it in code. The idea is still the same, but the difference is that now AI can take on part of the developer’s work.

When working with AI, the specification should be specific enough to leave as little room for interpretation as possible. It should clearly define the requirements, expected behavior, constraints, and other details the AI agent needs to implement the application correctly.

Why formalize how business works with an AI agent

You might ask: why do we need SpecKit? Why not just use, for example, Claude Code with a good prompt?

The main thing SpecKit gives you is a structured specification. It captures not only what needs to be built, but also project rules, requirements, constraints, technical decisions, individual tasks, and ways to verify the result.

In practice, it creates a large, structured knowledge base of rules and project context for the agent, made up of many text files.

If you try to pass all of this through a regular conversation with Claude Code, the context keeps growing and may eventually exceed the context window. The agent may then lose track of important information or be influenced by irrelevant context. As a result, the output becomes less predictable.

With SpecKit, the agent has clear instructions to work. The task is described in the specification along with the necessary context and requirements, and the agent uses this information while working.

A regular prompt works well for small tasks, like making a quick fix. But for a full project that needs to be built from scratch, it becomes difficult to provide and maintain all the necessary context in a single conversation.

The whole flow in simple terms

To understand the flow at each step from a human point of view, rather than from the terminal, it’s enough to look at this diagram:

The flow from product definition to execution

Here’s what the process looks like:

Constitution

Constitution is the main set of project-wide rules, principles, and constraints in SpecKit. It has a high authority for the AI agent. Here, we agree upfront on how we name key entities, what rules and security requirements apply across the whole app, and which things should not be interpreted in different ways. For example, if the API for user data is called the User API, we use that name everywhere from that point on. The same applies to common project-wide settings, like requiring phone numbers to use the E.164 format. So, the agent doesn’t have to ask about the same things every time, and the documentation stays clear and consistent.

Specification

Specification describes what the system should do from the user’s point of view — what actions they can take and what should happen in response, and how it should behave in different scenarios and edge cases.

Design

Design shows what all of this should look like. The designs are linked to the specification, so the agent understands the logic and the expected visual result.

Contracts

Contracts define how the app communicates with external systems and APIs, including the data exchanged, request and response formats, and expected behavior.

Plan

Plan turns the requirements into a technical implementation approach. It defines the tech stack, libraries, and other constraints. For example, we specify React Native and Expo, so that the agent doesn’t choose the technology on its own.

Tasks

Tasks are created based on the specification, design, contracts, and plan. Each task has a clear description and clear criteria for when it is considered complete.

Execution

Execution is the process of implementing the tasks. The agent writes and updates the code, verifies the implementation, completes the task, and moves on to the next one.

So, first we set the general rules and a common language for the project. Then we describe the product and technical requirements in detail. After that, we turn everything into specific implementation tasks.

EARS syntax vs. human language

You might ask — what’s wrong with regular requirements written in plain human language? The thing is, the specification needs to be as clear and detailed as possible. For an AI agent, any ambiguity leaves room for interpretation. If a scenario isn’t described, the agent will either ask a question or decide for itself how the system should work. In that case, the result may not match what you expected.

We used Easy Approach to Requirements Syntax (EARS), an approach that helps structure requirements more clearly to avoid this. This made it harder for the AI agent to interpret them in its own way or fill in missing details. For example, instead of a general description, we defined specific behavior: a user clicks “Delete account,” and the system should show a confirmation window.

A specification with fewer gaps means less time spent later on fixes and clarifications.

How to test the interface before development

Our team used a clickable HTML prototype as a quick way to test the future interface with the client before development started. This was part of our AI for rapid prototyping approach. In Claude Design, we took the designs from about 50% to a complete set of screens and built a prototype that covered the main user scenarios.

The client could go through these scenarios, see what worked well and what didn’t, and give feedback right away. We quickly made the necessary changes to the prototype, so we could solve many questions before they reached development.

API as part of the AI agent’s context

The AI agent needs a clear description of the API so it can describe the contracts correctly. OpenAPI works well for this because it provides endpoints, requests, and responses structured in one place. This makes it easier for the agent to understand the API and use this information when working on the project.

If you only have a Postman Collection, it usually needs some extra preparation because it doesn’t give the same level of formal API description as an OpenAPI specification.

Controlling the AI agent’s work

To keep track of the agent’s work, our specialists split the development into milestones of around 10 related tasks. Each task had clear completion criteria, and the rule “one task = one commit” gave us checkpoints. If the agent went in the wrong direction, we could roll back, clarify the instructions, and run the task again.

The agent worked through the whole milestone step by step, and we checked the result at the end of each block. Each milestone started with a fresh context, without the history of previous milestones, so earlier discussions would not influence the agent's work.

The code wasn’t rewritten manually. From the start, we agreed that if something needed to be fixed, we would also do it through AI.

So, in this experiment, the AI agent was the tool we used for implementation. If we weren’t happy with the result, we didn’t edit the code manually. We explained to the agent what needed to be changed and worked through it with the agent until we got the needed result.

Interim and final results

The first result wasn’t good enough for us. The main problem was that the specification wasn’t complete enough, and we quickly saw this in the agent’s work.

Our team went back to the constitution and specification, updated them based on what we learned from the first attempt, and went through the process again. The second time, the result was much better, so we continued developing the app.

In the end, we had a working app that didn’t need to be thrown away after the PoC. We could keep developing it and use it as the foundation for the MVP, which showed the potential of AI mobile app development for this kind of project. The architecture and security requirements had been planned from the start, so the code was ready for further development.

There were some challenges. The agent could see the designs, but it didn’t always match them exactly, so we had to check and adjust some screens. Toward the end, we connected a virtual mobile device, and it became clear that in the next iteration, the agent should have more ways to check the visual result and test the app on its own.

Key insights on AI development

The main takeaway is that we really can use AI for full-scale development. But the right approach, a clear methodology, and an understanding of how to work with it are needed.

When all of this is in place, AI can be used for full development while still delivering a result that meets the project requirements and can be developed further.

Before we started, we had little experience with React Native and Expo. Still, we managed to build the app. Along the way, we learned more about the technology, understood what the agent was doing and how the app worked, while still not writing the code manually.

Here’s what we learned while working on the project:

Where the real limits of “specification + agent” are

The agent can write code well when it has a clear specification, checks, and the right tools. But the requirements and the final result are still defined by a person: the clearer the task is, the closer the result will be. That’s why the person is still responsible for defining the requirements and doing the final check of the specification before development starts.

What turned out to be the main bottleneck

The main bottleneck turned out to be the specification: when it was incomplete, we saw the impact on the result right away.

We didn’t have any major problems with context. We used a model with a large context window and cleared the history between milestones or independent groups of tasks, so the agent only worked with the information it needed. This helped avoid overloading the agent with unnecessary context and reduced the risk of context interference.

Where the engineer’s effort really goes in this process

In this kind of process, the engineer becomes more of an analyst and architect. Most of the work goes into requirements, the specification, and technical decisions. AI agents can take over implementation, testing, checks, and part of code review, but the key analytical and architectural decisions still stay with the human.

How we spent our time on documentation and development

About 70% of our time went into requirements and documentation. At first, it feels slower because you need to turn a high-level idea into a clear specification, give the agent the right context, and go through the details.

But that’s what speeds up development later: the more clearly the result is described, the less the agent has to figure out on its own. The main idea and key decisions still stay with the person.

Where AI creates real gains and where it creates an illusion of speed

AI really does make coding faster, especially when the task is standard and clearly described. The illusion of speed appears when the agent gets a task that is too general: the result comes quickly, but then a lot of time goes into clarifications and fixes.

So the real gain doesn’t come from AI alone. It comes from combining AI with a clear understanding of the expected result and a good specification.

Why we can’t just give the agent everything at once

For small tasks, we can work with a regular prompt and very little documentation. But when it’s needed to build a project from scratch, we can’t just give the agent all the materials at once: the context quickly becomes overloaded, there’s too much extra information, and it becomes harder for the agent to stay focused.

That’s why it’s better to break large tasks into stages and give the agent only the context it needs for the current task.

Which decisions should always stay with a person

First of all, you can’t leave the specification to the agent. If you tell it, “Surprise me”, it can come up with a lot on its own. But if you need a specific result, you need to know what you want to get and clearly define it.

At the same time, our experience was limited to a PoC in a controlled environment, without production or high-risk operations. The more autonomy and responsibility you give to an AI agent, the more important human oversight becomes. Production systems and sensitive operations require additional safeguards and should be considered separately.

Key takeaways and recommendations

If a team is starting its first SDD project, we recommend focusing on four things:

Work through the constitution carefully

This is the foundation of the project: the general rules, constraints, and shared agreements that the agent will follow later.

Define security requirements separately

You need to decide upfront what can and can’t be done with logins, passwords, tokens, and user data.

Have clear checkpoints

The “one task = one commit” rule worked well for us: if the agent goes in the wrong direction, you can quickly roll back and try again.

Don’t keep fixing things as you go

If the agent starts changing things that are not related to the task, it’s better to stop and check the task itself or the context. Usually, that’s where the problem is.

For the first step, you only need an AI agent, a repository, a basic product description, the main requirements, and a general direction for the design. You don’t need fully complete documentation at the start — you can work on the specification and other documents together with AI before coding begins.

SDD is quite universal: you can use it to build something from scratch, work with existing systems, or make small changes. The size of the task may change, but the basic principle stays the same — the clearer the specification, the more predictable the result.

Modern AI models can already write good-quality code. The main question is how well you guide and control them.

A person has experience and knowledge, while AI has a large amount of knowledge about code and existing approaches. It can solve the same task in different ways. If you don’t set clear boundaries and keep an eye on the result, you can end up with hard-to-read code and technical debt.

So, the quality of the result depends not only on the AI itself, but also on how you work with the agent: how clearly the requirements are defined, what context it has access to, and how well the checks are set up.