# SaaS MVP where we gave away a fifth of the scope: Vertom AI > We built Vertom AI, a SaaS platform with an AI voice agent and a social setter. We never wrote the voice engine from scratch: we backed a ready provider, then swapped it for another one in a single day. - **Canonical URL:** https://appwave.dev/en/portfolio/saas-mvp-where-we-gave-away-a-fifth-of-the-scope-vertom-ai - **Language:** en - **Updated:** 2026-10-03 --- - **Client:** Vertom AI - **Industry:** SaaS – sales automation - **Published:** 2026-10-03 - **Author:** Jakub Dulas - Co-Founder, Backend Developer - **LinkedIn:** https://www.linkedin.com/in/jakubdulas/ ## Results in numbers - **~1/5** — of the scope built on a ready provider instead of by us - **1 day** — to swap the voice engine provider, no downtime - **2 stages** — each accepted on a test environment first, then on production - **since 09/2026** — platform publicly available ![Five modules linked by a glowing wave. One module lifted out of its socket with a new one ready to slot in, while the wave runs on unbroken.](https://cms.appwave.dev/uploads/saas_mvp_voice_agent_swappable_engine_eedbcc1a74.webp) Vertom AI is a SaaS platform where an AI voice agent handles phone conversations with leads and a social setter answers Facebook and Instagram messages and books meetings. We built its first version as a SaaS MVP: the panel, the conversation and campaign logic, the third-party integrations, and the data layer. The platform has been publicly available since September 2026. The most important decision of the project was made before the contract was signed, and it was about the voice engine. Instead of pushing for a bigger scope on our side, we confirmed that a ready external provider was the right call at this stage. About a fifth of the scope that could have stayed with us was built on that component. A few weeks later, that decision paid off in a way nobody expected. If you are building the first version of your own product, you know the question this page answers: how do I know a vendor will recommend what is good for the product rather than what grows their invoice. No declaration settles that. A project record can. ## Why we didn't pitch ourselves to build the voice engine We could have built the voice engine ourselves. We have the skills for it, and a bigger scope would have meant a bigger invoice. Instead we confirmed that the right call at this stage was a ready component from a proven external provider, with the logic, integrations, panel, and data staying with us. The reason does not change from project to project. In a first version, you build what does not exist on the market yet and buy the rest off the shelf. A voice engine sits on that shelf in several proven variants, so writing one from scratch would eat the schedule long before anyone learned whether the product was needed at all. An in-house engine also means owning every mistake in every conversation, on top of a business hypothesis nobody has validated yet. The consequence is countable: about a fifth of the scope that could have stayed with us was built on that ready component instead. We described this same mechanism earlier, without naming the project, in a post on [what it looks like when an AI agent development company argues against its own scope](https://appwave.dev/en/blog/when-an-ai-agent-development-company-argues-against-its-own-scope). We do not name the provider; that boundary was agreed with the client. ## We swapped that same engine for another provider in one day Picking a ready provider is not a one-time decision. We started with one voice engine provider. After a few weeks it turned out not to meet the client's business requirements, so we moved that layer to a different one entirely. It took about a day. The app kept running the whole time, and nothing else in the system had to be touched, because we had built it from the start so the engine provider could be swapped without rewriting everything around it. That is a consequence of the decision made before the contract, not a separate feat. A project meant to react quickly to what the market says should be built so that changing a provider is a day's work, not a month's. ## What the SaaS MVP included, and what it deliberately left out Version one covered what the client brought in, trimmed to a shape that could be built and accepted in stages: a panel for the client's team, conversation and campaign logic, third-party integrations, and the data layer. One thing was deliberately missing. An in-house voice engine built from scratch is not a gap in the product; it is a postponed investment waiting for proof that it is worth making. How we separate version one from everything that can wait is covered in our post on [MVP cost and what belongs in version one](https://appwave.dev/en/blog/mvp-cost-what-belongs-in-version-one). ## How the SaaS MVP development ran: two stages, weekly sprints Work ran in weekly sprints, with a weekly status meeting where the client saw a working version instead of a report. The whole project was split into two stages. Each stage had a two-step acceptance: first a test environment where the client ran acceptance tests, then production with a stabilisation period, after which the stage was considered closed. "It works" was never a matter of opinion; it was a list of criteria checked twice. The slowest part of projects like this is not writing code. It is the verification of integrations on the providers' side, meaning their approval of the app's access to user data. We cannot speed that process up or route around it, and neither can any other vendor; all we can do is arrange the schedule so the providers' clock runs in parallel with ours. That is why the features requiring verification were built first. ## Who owns the code, the infrastructure, and the AI bills The code went into a repository the client could access from day one, and the economic rights transfer with the payment for each stage. The infrastructure runs on the client's own cloud account, and the third-party service accounts are registered to the client, not to us. The client pays AI model providers directly, with no margin added by us, so every bill is visible. If the collaboration ended tomorrow, the client would keep a working system, the code, and the documentation, not a licence to someone else's product. ## What the work looks like after launch The platform has been publicly available since September 2026, and Vertom is on our maintenance care. The team that runs it includes a person who built the system, not an assigned account manager. The code carries a 12-month warranty regardless of any care package: defects in our work are fixed free of charge. AppWave works from Łódź, Poland. What Vertom pays is not something we will publish; that is the client's business. Our entry point is public: the first [AI MVP scope](https://appwave.dev/en/services/mvp-ai) starts at PLN 35,000 net, preceded by paid scoping workshops credited against the project price. Post-launch maintenance starts at PLN 3,875 net per month; the [calculator](https://appwave.dev/en/calculator) breaks it down. ## What this project does not prove It does not prove we know Vertom's numbers: user counts, revenue, and campaign performance belong to the client and will not appear in our materials. It does not prove we shrink our own scope in every project either. In most projects there is nothing to hand off, and once a hypothesis is validated and a product has users, building your own engine can be exactly the right move. And this page is not for everyone: if you are looking for the cheapest vendor, that is not us. ## Who this model is for This way of working is for founders building the first version of a product who want to test the scope conversation before signing anything. We start with workshops: you leave with a written scope, flow mockups, and acceptance criteria, and that document is yours even if you pick another vendor. The rule from this project applies everywhere: build the one thing that can be sold first, then add the rest based on what the first customers say. If you want to compare your scope with what an [AI MVP](https://appwave.dev/en/services/mvp-ai) covers, start there. If you would rather talk, [book a call](https://appwave.dev/en/appointment): 45 minutes, answered by a co-founder, no sales deck. ## Questions & Answers (FAQ) ### Every vendor promises delivery. How do I verify it? Not by the promise, but by the record. In the Vertom AI project we did not push the client toward a bigger scope on our side, even though we could have built the voice engine ourselves and billed more for it. We confirmed a ready provider was the right call, and designed the system so it could be swapped later without pain. There is also a check smaller than a contract: paid scoping workshops, which end with a written scope, mockups, and acceptance criteria you can take to any vendor. ### Who owns the code, and what happens if we part ways? The code sits in a repository you can access from day one, and the economic rights transfer to you with the payment for each stage. The infrastructure and third-party accounts are registered to you, not to us. If the collaboration ends, you keep a working system, the code, and the documentation. That is how the Vertom AI project was set up. ### What does an MVP cost, and what sits outside the price? Our first MVP scope starts at PLN 35,000 net, with the final amount fixed after the workshops and before the contract is signed. Infrastructure and AI model costs sit outside the price: you pay the providers directly, with no margin added by us. What Vertom paid stays between us and the client. ### Does a third-party engine lock me into that provider? To the same degree an in-house engine locks you into its own build time and budget, except a ready component can be replaced. In the Vertom AI project, swapping the voice engine provider took one day and didn't touch the rest of the app, because we'd built it from the start with that kind of change in mind. The rest of the system is already the client's property. ### What happens if something breaks after acceptance? Defects in our work are fixed free of charge for 12 months from acceptance, whether or not you choose a care package. Maintenance care is a separate, optional service, and its team includes a person who built your system. Vertom has used it since launch. --- ## About AppWave AI development company from Łódź, Poland. We build custom AI software, automation agents and web applications. We co-create them with the client and guarantee every system we deliver. - **Legal name:** AppWave sp. z o.o. - **Address:** ul. Kolumny 147E/1, 93-611 Łódź, Poland - **Phone:** +48 538 441 413 - **Email:** office@appwave.dev - **Business hours:** Monday-Friday, 09:00-17:00 - [Free consultation](https://appwave.dev/en/appointment)