shardana.ai does MVP development for startups and SMEs: it designs and builds the first working version of a digital product, with the minimum set of features needed to put it in front of real users and find out whether it works. The studio is based in Cabras, in the province of Oristano, and works with founders and companies across Italy, mostly remotely.
Many MVPs get lost before they reach users. The scope grows at every meeting, the stack is chosen because it is fashionable, the first developer leaves the project and nobody else understands the code. Or the opposite happens: a fragile demo goes live and cannot handle the first hundred sign-ups. Our work sits in between: build little, and build it well.
What is an MVP, and what is it not?
An MVP (Minimum Viable Product) is the smallest version of a product that lets you test a market hypothesis with real users. "Minimum" refers to the features, not the quality: a few things, built so that they work every time. An MVP is not a clickable prototype, which shows an idea but cannot be used, and it is not version 1.0 with everything you might one day want to offer. It is a real product, with users, data, authentication and, if needed, payments, reduced to the path that proves its value. For a marketplace it may be enough to match supply and demand in a single category; for subscription software, to automate a single workflow for a single type of customer. Everything else is explicitly postponed until the data says it is worth building.
| Aspect | Prototype | MVP | Product 1.0 |
|---|---|---|---|
| What it is for | Showing an idea and gathering reactions | Testing a hypothesis with real users | Serving an already validated market |
| Who uses it | Team, investors, a few testers | First customers or pilot users | All customers |
| What it contains | Screens, fake data | One complete path, real data, basic security | Several paths, integrations, structured support |
When does it make sense to develop an MVP, and when not?
It makes sense when you have a precise hypothesis to test and a group of users you can actually reach: a sector you know, a waiting list, your company's current customers. It makes sense when you need to show traction to investors or partners with real numbers rather than slides. It also makes sense for an SME that wants to launch a new digital service without stopping day-to-day work, or to turn into a product a process it currently handles by hand.
It does not make sense when the hypothesis can be tested without writing code. Often a landing page with a booking form, or a service delivered by hand to the first ten customers, tells you in two weeks what an MVP would tell you in two months. We tell you so in the first conversation: a project started for no reason costs you money and does us no good.
How is an MVP developed, phase by phase?
The phases are always the same; what changes is how long they last. The table shows our typical path for a web MVP of medium complexity, about six weeks long. It is a reference model, not a contractual commitment: the actual timeline is set in the proposal, after discovery, and depends on scope, integrations and how quickly decisions are made.
| Phase | Typical period | What happens | What you get |
|---|---|---|---|
| Discovery | Week 1 | Hypothesis, users, critical path, metrics, constraints | Scope document: in, out, later |
| Architecture | Weeks 1–2 | Stack, data model, external services, environments | Documented architecture and prioritised backlog |
| Incremental development | Weeks 2–5 | Weekly releases to a test environment, demos and feedback | A product that grows every week |
| Quality gate and launch | Week 6 | Tests, security, performance, measurement | A product in production that can be measured |
| Handover | After launch | Documentation, access, session with your team | A product you can evolve with whoever you choose |
1. Discovery: deciding what not to build
Discovery starts from one question: which hypothesis must this MVP prove? From there we define with you the user it is for, the critical path (from the first login to the moment the user gets the promised value) and the metrics that will show whether the hypothesis holds: how many complete the path, how many come back, how many pay. We also list the constraints: personal data, payments, mandatory integrations, external deadlines. The result is a short scope document with three columns: what goes into the MVP, what stays out and what will come later. This is the phase where you save the most, because every feature removed here is work you do not pay for.
2. Architecture: simple today, extensible tomorrow
An MVP does not need microservices, clusters and ten environments. It needs a simple architecture that does not force you to rewrite everything when the first customers arrive. This usually means a responsive web application or a PWA before a native app, a single application organised in modules, a relational database and established external services for authentication, payments and email. The reference stack includes PHP and Laravel, Node.js and TypeScript, React and Vue.js, MySQL. The main choices go into a short decision log: whoever comes later will know why the system is built this way.
3. Incremental development: one release a week
Development proceeds through weekly releases to a test environment you have access to. Every week you see the product grow, you try it and you decide with us the priorities for the following week. The backlog is shared and prioritised: if feedback changes the priorities, something moves further out instead of the project getting longer. No two-month tunnel with a surprise at the end.
4. Quality gate: what we check before going live
Before launch, the product goes through a set of checks agreed at the start. Automated tests on the critical paths, such as sign-up, payment and the main action. Code review. Basic security checks on authentication, permissions, personal data and backups. Performance on smartphones. Analytics events already active, to measure from day one the metrics decided in discovery. Error logging and monitoring. If a blocking check fails, the launch moves: it is a rule we set together before writing the first line.
5. Handover: the product stays yours
An MVP that only its author knows how to run is a risk for your company. That is why the code lives in a repository in your name, the infrastructure and external service accounts are yours, and the documentation explains how to start the project, how to release it and how it is organised. We close with a handover session with your team or with whoever will look after the product. Afterwards you can choose: keep developing it with us, bring in an internal team or carry on by yourself.
What do you receive at the end of MVP development?
- The product in production, with a domain and infrastructure in your name.
- The source code in your repository, with the full history of changes.
- Three separate environments: development, test and production.
- Technical documentation: local setup, release, architecture and decisions taken.
- The dashboard with the metrics agreed in discovery.
- The quality gate report, with the checks passed and the known limitations.
- The backlog of postponed features, prioritised according to what you learned from users.
An example of scope
An illustrative example, not a client case. A startup wants to test whether local guides would pay to receive commission-free bookings for excursions. The MVP includes the excursion page, the availability calendar, booking with online payment, email confirmation and a basic dashboard for the guide. The native app, reviews, chat and the loyalty programme stay out. Group offers and integration with external sales channels will come later, if the numbers justify them. There is one main metric: how many of the invited guides receive at least one paid booking in the first month.
What do we need from you to get started?
Above all, someone who decides. An MVP slows down more because of a postponed decision than because of a bug: we ask that the founder or the product owner attends the weekly demos and answers questions within a few days. We then need access to some users for testing, the product's content and copy, and accounts in the company's name: domain, cloud services, payment provider. If you already have mockups, market research or an earlier version, bring them to the first meeting: we use them rather than starting from scratch.
How much does it cost to develop an MVP?
The cost of an MVP depends on the agreed scope, which is why we do not publish a one-size-fits-all price list. The main factors are the number of user types and paths, integrations with external systems (payments, management software, third-party APIs), the presence of artificial intelligence components, security and compliance requirements, the platforms to cover and the state of the design, ready or still to be designed. On top of these come the recurring costs of hosting, external services and any AI models, which grow with usage and must be estimated from the start. After the first conversation you receive a written proposal with phases, deliverables and costs, and you can start with discovery alone before committing to the whole development.
| Factor | Simpler MVP | More complex MVP |
|---|---|---|
| Users and paths | One user type, one path | Several roles with different permissions |
| Integrations | Payment and email | Management software, external APIs, synchronisation |
| Platforms | Responsive web or PWA | Web plus native apps |
| Artificial intelligence | None, or in a single feature | At the core of the product |
| Design | Interface already defined | To be designed from scratch |
Can you develop an MVP with artificial intelligence?
Yes, when artificial intelligence is the value of the product and not a label. An assistant that answers questions on a sector's documents, a system that extracts data from invoices or contracts, a search that understands the meaning of questions: in these cases the AI must be tested straight away, because it is the riskiest hypothesis. In discovery we define how to measure the quality of the answers and how much each use of the models will cost. If, on the other hand, the AI does not change the user's experience, we leave it out of the first version. For projects where AI is the heart of the system we work with the same method described in AI development for businesses; if the MVP is an internal tool that has to connect email, CRM and management software, see also AI automation for business processes.
What experience do we bring?
shardana.ai was founded in 2026, but the work rests on more than 25 years of experience of its founder, Maurizio Brioschi, in software engineering, backend development, systems architecture and leading technical teams. In MVPs this experience is mostly used to choose what not to do: which feature to postpone, which external service to use instead of rewriting it, which shortcut will become a debt that is hard to pay off. We do not publish client cases we cannot document: in the first conversation we go into the technical choices for your idea.
Where do we work?
We work with startups and SMEs across Italy, mostly remotely: discovery, weekly demos and releases work well online. The office is in Cabras, in the province of Oristano, and for projects in Sardinia in-person meetings can be arranged, starting with the discovery workshop.
Frequently asked questions
- How long does it take to develop an MVP?
- For a web MVP of medium complexity our typical path takes about six weeks, from discovery to launch. It is a reference, not a guarantee: complex integrations, native apps or slow decisions make it longer, while a very narrow scope makes it shorter. We set the timeline of your project in the proposal, after discovery.
- No-code tool or custom development?
- It depends on what you need to test. No-code tools are fine for validating an idea quickly, when the logic is simple and volumes are low. Custom development makes sense when the product has its own logic, has to integrate with other systems or has to grow without rewrites. Sometimes the right answer is to start with no-code: if so, we will tell you.
- Is the source code mine?
- Yes. The code lives in a repository in your company's name, and the rights are set out in the contract before we start. The infrastructure and external service accounts are also in your name.
- Can you work with our internal technical team?
- Yes. We can develop the MVP and hand it over to your team, or work together from the start, with shared code reviews and architecture decisions taken jointly.
- What happens after launch?
- We analyse with you the metrics decided in discovery and prioritise the backlog according to what users actually do. You can continue development with us, hand it over to your team or stop, if the data says the hypothesis does not hold.
- Do you also develop mobile apps?
- Yes, but for an MVP we almost always start from a responsive web application or a PWA, installable from the browser: it costs less and updates without going through the app stores. We move to native apps when you need phone features the web does not offer. You will find the details on the page about mobile apps and PWAs.
Related services
- AI development for businesses: custom AI software, from chatbots to agents.
- AI automation for business processes: processes across CRMs, management software, email and documents.
- Custom web application development: when you need management software or a portal built around the processes of an established company.
- Mobile apps and PWAs: when your MVP needs to live on the phone.
- About us: the studio, the method and the founder.
Tell us the idea you want to put to the test
Describe the product, who it is for and which hypothesis you want to test. We will reply with a first assessment and, if it makes sense, with a proposal for the discovery.