Vladeta Radovanovic started Presta in Belgrade in the winter of 2014. Twelve years on, the agency builds web apps, Shopify stores and AI automation, mostly for startups and companies that are growing fast. Its past clients include UNESCO and Audi, and the About page still describes the goal he started with: products that make a lasting difference for the business using them.
Not every founder who contacts Presta gets a build right away. If the idea isn’t clear yet, they’re usually pointed to a paid Discovery Workshop first. It takes one to two weeks and ends with a written scope and a fixed price. One of their MVPs, Trinigence, shipped three months earlier than planned.
Presta has been on NoRobots once before, in a piece about keeping clients for the long run. This time we wanted to talk about MVPs: what makes the cut for a first release, how to tell a founder isn’t ready to build, and what happens when you strip a product back.
How to choose MVP features for the first release
Presta often helps startups turn an idea into an MVP. How do you decide which features are essential for the first release and which ones should wait?
We start with one question: what is the single thing a user must be able to do for this product to prove its point? Not the vision, not the pitch deck version, just the one action that tells you whether people care. Everything that directly supports that action goes into the first release. Everything else goes on a list we call “after we learn something.”
In practice, founders come to us with 30 or 40 features, and most of them are reasonable. The problem is that every feature you add before launch is a guess, and every guess delays the moment you get real feedback. So we sort features into three buckets: things the core flow can’t work without, things that make the product feel trustworthy (login, payments, basic security, a clean onboarding), and things that are nice but based on assumptions about how people will use it. The first two buckets ship. The third waits.
A simple test we use: if a feature only makes sense once you have 1,000 users, it doesn’t belong in a product that has zero. Admin dashboards, advanced analytics, referral programs, multi-language support, complex permission systems: all of these are real needs eventually, but almost never on day one.
We also push founders to think about what can be done manually at first. If an AI recommendation engine can be replaced by the founder personally sending recommendations to the first 50 users, that’s weeks of development saved and a lot of learning gained. You automate once you know what’s actually worth automating.
When a founder isn’t ready to build yet
How can you tell when a founder needs a product built, and when they actually need more customer validation or a clearer strategy first?
Honestly, it usually becomes clear in the first conversation. If I ask, “Who is your customer?” and the answer is “everyone,” or I ask, “How will you reach your first 100 users?” and there’s a long pause, that founder doesn’t need developers yet. They need clarity.
There are a few signals we look for. Have they talked to potential customers, not friends and family, but people who would actually pay? Do they know what those people use today to solve the problem, and why it’s not good enough? Can they describe their go-to-market in a few sentences? If the answers are vague, building the product will just turn a cheap mistake into an expensive one.
This has become even more important with AI. Today, almost anyone can build an MVP in a few weeks, so building is no longer the hard part or the competitive advantage. Distribution, positioning and understanding the customer are. I’d rather tell a founder “don’t hire us yet” than take a 50,000 EUR project that will need a full pivot three months after launch.
When things are unclear but promising, we suggest a Discovery Workshop instead of a full build. It’s a short, paid phase where we map the users, the core problem, the riskiest assumptions and the smallest version worth building. Sometimes the output is a lean scope and a fixed price. Sometimes it’s a clickable prototype to show to customers before writing any code. And sometimes the honest conclusion is that the idea needs more validation, and that’s a good outcome too, because it saved the founder months and money.
How cutting features made a better product
Can you share an example where removing a feature or simplifying an idea led to a better product?
One that comes to mind is a startup that came to us wanting to build a two-sided marketplace connecting service providers with customers. The original scope had everything: a customer app, a provider app, in-app chat, booking with calendar sync, payments with split payouts, ratings, a loyalty program and an admin panel. On paper it made sense. In reality it was about six months of work before a single real booking could happen.
During discovery, we asked which side of the marketplace was harder to get. The answer was clearly the providers, and the founder already had personal relationships with about 20 of them. So we flipped the approach. Instead of two apps, we built a simple web booking flow for customers and gave providers a lightweight dashboard. No chat (phone and email worked fine), no loyalty program, no split payouts at first; the founder handled payments manually for the first few weeks.
The first version went live in roughly six weeks instead of six months. And because real bookings started early, the founder learned things no spec could have told us: customers cared much more about seeing availability instantly than about ratings, and providers wanted reminders far more than they wanted a fancy calendar. The features we eventually added were the ones users actually asked for, and a few of the ones we cut never came back because nobody missed them.
That’s the part founders often find surprising. Cutting features doesn’t make the product weaker. It makes it sharper, because every remaining feature has to earn its place.
Final Thoughts
Vladeta keeps it practical. Work out the one thing that proves the idea, ship only what supports it, and do the rest by hand until you know it’s worth building. He’s also happy to tell a founder not to hire Presta yet, which is probably part of why the agency is still around after twelve years. The marketplace story makes the point better than anything else in the interview: live in six weeks instead of six months, with the later features coming from real users and not from a spec.
Explore More Agencies
If you’re an agency, designer, or startup looking to boost your visibility, you can join NoRobots and become part of our curated network of trusted businesses. If you’re a brand or client searching for the right partner, our platform helps you discover agencies, designers, and startups you can rely on. Browse the listings and find the right fit for your next project!
