Prototype in a day: from idea to working app
A digital use case often exists only in slides and discussions until someone puts it into code. With One Day Build, Appfront delivers a working prototype of your idea in a single working day. No Figma click-through, no specification document: a live application that your colleagues, users or board can open and test straight away.
What exactly is a one-day prototype?
A one-day prototype is a working first version of a digital idea, built in a single working day by a small team. It is not a design that still needs developing, nor a demo running on localhost. It is an application running on a real URL, with genuine interaction, suitable for showing to stakeholders or letting end users try out.
The concept is not new: Google Ventures' design sprints apply a similar acceleration to design challenges. What sets One Day Build apart is that the end result is not a clickable sketch but actual code. An interactive client portal, a scheduling tool with real logic, a dashboard that loads data from a test file: whatever the use case, it is built for real.
The offering fits a broader trend: AI-assisted development has drastically increased how fast applications can be built, and that changes when "quickly trying something out" becomes realistic. Appfront combines that speed with ten years of experience in custom software development, so the prototype not only works but also provides a foundation for any follow-up.
Working code, not a mock-up
The difference from a clickable Figma file is fundamental: a prototype has real logic, can process data and behaves like a live application. The difference between MVP and prototype: a prototype validates the idea, while an MVP goes to its first users.
At the table, not through tickets
A one-day prototype is a collaborative working session. You are in the room, help decide on scope and see choices take shape. No lengthy briefings, no radio silence between handover and feedback.
A real URL at the end
At the end of the day you receive a live link that you can share with colleagues, clients or investors. No "we'll send it over soon", no demo environment that only runs on a laptop.
When does a one-day prototype suit your situation?
Not every software challenge calls for a prototype-in-a-day. For a complex platform with multiple user roles, sensitive integrations and compliance requirements, you are better off starting with a thorough consultancy engagement. But for the stage where an idea has no support yet, no concrete form and no price tag, a working one-day prototype is often the quickest way forward.
Good moments for a One Day Build
- A board member has an idea that is hard to explain in text or slides
- There is an investment proposal that needs more tangibility
- An internal department wants to demonstrate that a process can go digital before IT commits capacity
- A product team wants to compare three different solution directions side by side
- A sales or customer success team wants to show something tangible to a prospect
- A founder wants a working example to bring to the table for an investment round
When another route is better
- The use case is well defined and you already know you want to go into production: start directly with a more extensive prototype engagement
- Complex integrations with multiple existing systems are required
- The application must meet strict compliance requirements (medical, financial supervision)
- Users are already waiting for a working version, in which case a custom development engagement is more appropriate
- The ambition is a full product, not an experiment: start with scoping
Which use cases fit within a working day?
A good One Day Build has a sharp scope: one core flow, one clear user, one question to prove. That sounds restrictive, but within those boundaries a great deal is possible, because modern frameworks and libraries make building interactive interfaces faster than ever. Examples of what is achievable in a single day, described generically because every use case is different:
Self-service customer portal
An interface where customers log in, view their details, submit a request and track its status. A working first version of a portal application as proof of concept for your internal discussion.
Operational dashboard
An interface that pulls data from a spreadsheet or API and visualises it in charts, tables and filters. Comparable to a custom KPI dashboard, but built in day form to prove the concept first.
Planning or registration tool
An interface where a team plans tasks, logs hours, keeps track of stock or records another operational process. A first sketch of a workflow application you can put in front of end users.
Internal registration app
A form-driven tool that collects data and passes it on to a database or existing system. For example, an intake app, a reporting system or a simple intranet web app.
AI-driven feature
An interface built on top of a large language model that performs a specific task: summarising documents, answering questions, generating content. A first prototype of an AI application to test whether the output is useful.
Mobile app sketch
A prototype that also works on smartphones, such as a field-work app or a member app. Often built as a responsive web app that can later be developed further as a native or hybrid app.
How does such a working day broadly unfold?
A One Day Build is deliberately tightly structured. A working day is short, so every phase has a fixed goal. The full story, including what you send in beforehand, who sits at the table and what you take away afterwards, is on the OneDayBuild page at onedaybuild.nl. In broad terms, the day looks like this:
Before the day, you share the use case and a few references. We choose the right stack, set up the project environment and make sure we can build straight away on the day itself, rather than installing tooling first.
In the morning, we decide the sharp scope together. Which core flow must work? Which screens are essential? What do we explicitly leave out of this prototype? A good scope is the difference between a finished prototype and a half-finished delivery.
Most of the day is spent building, with you at the table. We regularly show what works and adjust based on your feedback. Decisions that would normally take place through tickets and emails are made on the spot.
At the end of the day, the prototype is live at a real URL. You receive access to the code, a short written summary of the choices we made and, if you wish, a roadmap for any follow-on project.
What do you get at the end of the day?
A working prototype is the visible result, but the most important thing is that you can move forward. The prototype is meant to support decisions, not to be a product in its own right. We make sure you can act on it straight away, whether the outcome is "we carry on" or "we stop here".
The working prototype
- A live application at its own URL, shareable with your team or stakeholders
- A working core flow with realistic data: no lorem ipsum, no empty screens
- A responsive interface that works on laptop, tablet and phone
- Access to the source code, in a Git repository registered in your name
The foundation beneath it
- A choice of tech stack suited to where this idea could eventually grow
- A written summary of the choices made and why
- A rough roadmap outlining what a follow-on project would involve
- An honest view on whether a follow-up makes sense at all, and if so, in what form
Why does prototyping in a day actually work?
Building a prototype in a day would have been unthinkable ten years ago. Three developments have made it feasible, and all three have accelerated in recent years:
Mature frameworks
Tools such as Next.js, React and Tailwind handle the tedious work (routing, styling, forms) out of the box. What remains is the logic that makes your use case unique.
Database-as-a-service
With cloud Postgres providers, Firebase and similar services, you have a working database and authentication within minutes. No need to configure servers on the day itself.
AI-assisted development
Code assistants such as Cursor and Claude speed up writing standard code. The developer stays in the driving seat, but spends less time on boilerplate and more on the choices that matter.
It isn't "magic", and it won't solve every problem. Production software has different requirements (testing, security, performance, compliance), and we take plenty of time for those. But for answering the question "can this actually be done?", a working day is often more than enough. Read in our knowledge base on software costs how a one-day prototype compares with larger development budgets.
Which technology do we use as standard?
The choice always depends on the use case, but there is a commonly used foundation with which we can start every One Day Build. The stack is deliberately mainstream, with no exotic experiments, so that any follow-on project doesn't get stuck on odd choices made on the day itself.
Frontend
For the interface we usually choose Next.js or Astro with React components. Both frameworks are well documented and widely supported, so any development team can pick them up later. We test mobile interaction through responsive design; for genuinely native behaviour we sometimes use Flutter.
Data, AI and hosting
For data we use Postgres through a managed provider, so we don't lose time on database administration on the day. AI features connect to established models via standard APIs. Hosting is cloud-managed by default, with your own domain name if you want one.
Why a One Day Build with Appfront?
Building a quick prototype can be done with countless tools today. The difference lies not in speed alone, but in what you get out of it and what you can do with it afterwards. Three reasons why organisations have their One Day Build done with Appfront rather than with a purely productisation agency:
Consultancy in the same seat
The developer building your prototype helps you think through the scope. What is the core question we want to answer? Which assumption is the riskiest? It is similar to our custom consultancy, but at a different pace.
UX thinking from the start
A prototype that looks messy gets no serious response from stakeholders. Our designers help shape the structure and feel, not as a separate design phase but in parallel with the build.
Real engineering, not vibe coding
The prototype is built so that a follow-on project can build directly on it. Standard project structure, readable code, no loose hacks that will have to be redone later. See our work for the software projects that have grown out of such starts.
What happens after the One Day Build?
A prototype is not an endpoint. It is a decision point. Based on what stands at the end of the day, you choose how to proceed, and you make that choice yourself, not under pressure. We broadly see four follow-up paths:
Build straight on to production
You're convinced, your stakeholders are convinced, and you're ready to move forward. We turn this into a regular custom software development engagement, with sprint planning, a dedicated developer team and concrete deliverables.
Taking it to MVP
The prototype has proven the core idea, but user roles, integrations and production requirements still need to be added. A web application development engagement or a broader AI application could then be a logical next step.
Taking it in-house, with light support
Sometimes an organisation has its own developer team and prefers to continue development internally. In that case we hand over the code cleanly and remain available on request for advice or outsourced pieces of work.
Not pursuing the idea
That is also a valid outcome. Sometimes the answer is that the idea doesn't work in this form, and the day has saved you far more than it cost. No lengthy project that stalls halfway through.
Does this sound like what you need?
Start with a short description of the idea and what you want to demonstrate. We'll let you know whether a One Day Build is a good fit or whether another engagement would make more sense. For the full proposition, availability and what to send in advance, see the OneDayBuild page.
Frequently asked questions about prototyping in a day
The questions we hear most often from organisations considering a One Day Build or wanting to validate a use case this way.
A prototype proves an idea: can this work, will people use it, is this the right direction. A minimum viable product (MVP) is a first production version that goes to real users and can generate revenue. A prototype comes before the MVP, not after it. You can read more in our knowledge base article on MVP versus prototype.
The current price, availability and what's included are listed on the OneDayBuild page at onedaybuild.nl. It also explains how the price compares with a possible follow-on engagement. We deliberately don't publish a price list on this page, as the terms are adjusted from time to time.
For a tightly defined use case, yes. This doesn't deny that a production app takes months to build, but for the question "does this core flow work the way we think it does?", a working day with an experienced team at the table is often sufficient. The crucial word is scope: a One Day Build that tries to cover too much won't produce a working prototype. That is why we keep the scope tightly controlled.
You do. At the end of the day you get access to the Git repository, and you can host the code yourself or have your own team continue development. No vendor lock-in. Even if you decide not to proceed with Appfront, the code remains yours.
A short description of the idea, the user it is intended for, and the central question the prototype needs to answer. Optionally, a few examples or references of similar interfaces. No technical specifications are needed, as we work those out together. The OneDayBuild page at onedaybuild.nl describes the preparation process in more detail.
In most cases, yes, provided the data isn't subject to strict compliance requirements. A spreadsheet with test data, a CSV export from an existing system or a few sample records is usually sufficient. For production data from sensitive systems, we ask in advance about any data processing agreements or restrictions.
We then turn it into a follow-on project. Depending on what the idea requires, that could be a custom software development project, an MVP build or a built-in feature in an existing system. In that case, we create a roadmap together with a sprint structure and targeted deliverables.
Yes, and that is often where most of the value lies. For organisations without an in-house development team, a working prototype is the moment to build internal support for a digital initiative. We are used to working with boards, innovation managers and operational teams who don't write code themselves.
One Day Build within our wider services
A One Day Build is an entry-level product, not a standalone activity. It fits within an ecosystem of services in which we guide organisations from the first idea to live software. For those looking beyond the prototype, these are the logical next steps or alternatives within our service portfolio:
Custom software development
Custom software development is the natural next step after a successful prototype. Full sprint-based engagements covering UX, development and handover.
Building a web application
Building a web application suits prototypes that are growing towards a real user base, with authentication, roles and integrations.
AI application development
For prototypes with an AI component, we run an AI application project, including evaluation of model output and cost structure.
Software consultancy
Not a One Day Build, but a project spanning several weeks? Our software consultancy supports you with architecture and technology stack decisions.
Prototype projects
Need something more extensive than a single day? A app prototype project covers several sprints with deeper development and user testing.
Review previous work
Curious which projects have grown out of similar questions? Our portfolio features examples of software projects in healthcare, transport and the public sector.
A prototype is quicker than an explanation
Whether or not the idea ultimately goes ahead, a working prototype sharpens the conversation, makes the decision easier and makes the next step more concrete. Tell us in a few sentences what you have in mind, and we will assess whether a One Day Build is the right format. For the full approach, availability and terms, see everything on the OneDayBuild page.