322. How much does it cost to build an app? And other questions non-technical founders are afraid to ask

How much does it cost to build an app?

Is my agency ripping me off?

How do I know if what they built is any good?

Am I being too demanding — or not demanding enough?

Every non-technical founder is terrified when they start working with developers. If you don't have a background in tech, you don't know what you don't know and asking AI can spin you down a rabbit hole. 

My guest this week has spent years on the other side of that conversation.

He knows what founders get wrong, what agencies hide, and what it actually costs to build a product. 

Vuk Nikolic leads Hurricane Studio — a development team that specialises in working with non-technical founders. 

Hurricane Studio is also the first ever sponsor of this podcast!

In the intro I explain exactly how we vetted them — because the process gives you a glimpse of how to choose a development partner yourself.

Listen to learn:

• How much it actually costs to build an MVP — with real budget brackets for three different types of product
• The single biggest red flag when evaluating a development agency 
• How to tell if your Lovable or no-code prototype is ready for real users 
• Why most projects fail because of communication, not technology — and the specific questions to ask before you sign anything

This episode is for you if:

• You are a non-technical founder who is about to hire developers for the first time
• You already have a development partner and want to know if they are the right one
• You have built something with a no-code tool and want to know what to do next

FREE GUIDE for non-technical founders: Hurricane Studio's Storm Survival guide

Book a call with Hurricane to discuss how to build your venture: https://hurricane.studio/

Timestamps:

• 00:00 – The most expensive mistake in hiring developers
• 00:20 – Introducing Hurricane Studios, first podcast sponsor
• 03:56 – How to spot red flags in your development team
• 06:47 – Signs your outsourced developers aren't being honest
• 10:34 – How to track progress when you can't read code
• 13:55 – Understanding feature trade-offs with developers
• 16:28 – How much it costs to build an MVP
• 19:48 – Why MVP launch dates always slip
• 22:27 – How to reduce your development budget
• 27:29 – Case study: taking a Lovable prototype to production
• 32:46 – The #1 sign of a trustworthy development partner

Follow and Review:

We’d love for you to follow us if you haven’t yet. Click that purple '+' in the top right corner of your Apple Podcasts app. We’d love it even more if you could drop an honest review on Apple Podcasts. Simply select “Ratings and Reviews” and “Write a Review” then a quick line with your favorite part of the episode. It only takes a second and it helps spread the word about the podcast.

Listen to our podcast on:

• Apple
• Spotify
• YouTube
• Audible
• Pandora

Transcript:

[00:00] Vuk Nikolic: If you just send a brief and a developer or agency says yes right away, I'd run away right away. There must be something that's problematic, something that's unknown. Because if everything's a yes, they're just there for the money, not to help you out. The partner, agency, or developer that does not disagree with you — that's the most expensive mistake you can make.

[00:20] Sophia Matveeva: Welcome to Tech for Non-Techies. This is a podcast for business leaders and non-technical founders building the future in the age of AI. Whether you've been in business for a hundred-plus years and you're looking to modernize, or whether you're building something new, this is the show for you. You'll learn how to come up with new ideas and make them come to life, no matter the size of your organization. I've taught tech and innovation at Oxford University, advise companies like Microsoft, and written for the Harvard Business Review. You're going to hear the frameworks and the thinking that I've built, tested, and taught at the highest level. And now it's your turn. Let's get started.

Hello, smart people, how are you today? In this episode, you're going to get a very practical lesson on how to work with developers as a non-technical founder. We cover how much it costs to build an MVP, what to do when the budget is creeping up and you need to cut it, and how to tell if your technical partner actually has your best interest at heart. You're going to get the answers to the key questions you ask me about working with developers as a non-technical person. Honestly, bookmark this episode and listen to it again when you're in the midst of building and hiring.

I'm also extra excited because you're about to hear from our first-ever podcast sponsor. Vuk Nikolic leads Hurricane Studios, a team of developers that specializes in working with non-technical founders. They've helped founders go from idea to their first product, and they've also rescued founders from badly written code and products that AI tools built but couldn't take to production — which is obviously super relevant for the age we're in, and you're going to hear a case study of that today.

As you might imagine, I get lots and lots of development studios pitching to be on the show, because the audience here is just so focused — there's literally no other show specifically focused on non-technical founders and business leaders who want to build innovative tech products and ventures. I turn most of them down, and I wouldn't select them to be a podcast sponsor. So actually, me selecting a podcast sponsor has been a bit like you, the non-technical founder, selecting your development team — we went through a pretty extensive due diligence process. First we researched the firm and the founder, spoke to Vuk extensively, and also sent one of our students to get an assessment of her product from him — so we weren't just doing research, we actually went to see what it's like working with these people. Our student had a positive experience, and you're going to hear about that later in this episode. When she reported it, I knew Vuk and Hurricane Studios were the real deal, and I wanted you to learn from them.

If you're working on a tech venture, or already have a product and wondering if you're going in the right direction — which I know is the case for many of you — or maybe you're an investor wanting to learn how much you should be investing and what founders should expect in terms of budget for their first product, this episode is going to be super useful. Listen to it, get the transcript from my website, and go back to it when you're making your launch plans.

Look, non-technical founders, as you know, we're terrified of handing over a lot of money to developers and getting something back that doesn't work and cost us quite a lot. You've actually been in this exact situation, when you were called in to check under the hood. Can you tell us about one of those times — what happened, what did you find, and what did you do about it?

[03:56] Vuk Nikolic: Yeah, sure. At Hurricane we've had this so many times. Funny enough, the first story that happened — my previous investor from a previous startup just tweeted that she needed some dev help. Since we stayed in a good relationship, I said, "Okay, I'll just help out" — meaning she needed somebody to take a look at code somebody else had done, no harm done, I just wanted to return the favor. I got access to it pretty quickly, did a mini weekend project, no contracts, nothing, just to help a friend.

What happened is I found pretty bad red flags. I'm on board with technical details, but it was obviously done by a junior guy — a bunch of spelling errors, database connections leaking, really in a bad state. I was being honest and said, "For me, this is not production-ready, this is not good, if you want, we can talk more." I emailed the founder and the investor at the same time, we got on a call, and I explained they had three options: get more senior developers from the company they were already working with, hire somebody in-house, or get another agency to help out, because obviously it wasn't working out.

But then I realized they had a big publication in the UK writing about them coming up soon — they needed to go live right away, and had burned a lot of money along the way with the wrong agency. So our team, just a few of us at a time, jumped in to help. We rebuilt the platform in about three months, luckily it was live, luckily the article came out, all good news in the end. But the problem was they had an agency they didn't trust — there was no transparency between them, they were just expecting everything to be fine, with nobody looking under the hood. So the main thing is: be careful who you work with, ideally get a recommendation and somebody to check it out, because that was their biggest problem. And I agree with founders — it's really hard to put a lot of money into unknown hands. That's a massive problem.

[06:47] Sophia Matveeva: That's a scary story, and I want to dig into the lessons here, because that's literally the nightmare of a lot of founders. You rescued it, but the real nightmare would be it never getting discovered, and then the FT is about to write about you and your product is crap. So — lessons learned: if you're getting that spidey sense with your agency that something ain't right, follow that sense and get an external advisor to look. What are your thoughts, what else?

[06:47] Vuk Nikolic: Absolutely. One of the biggest flags I saw — and unfortunately I was also part of those "crowd-pleasing" companies — is a founder comes in with a big laundry list of things that need to be built, and whether it's your internal developer, your CTO, or an agency, there's this trait of saying yes to everything. "Yeah, sure, we can build this" — technically I can build it, but missing the constraint of time, budget, clean constraints — just saying yes doesn't help you. If you send a brief and a developer or agency just says yes right away, I'd run away, because there must be something problematic or unknown. If everything's a yes, they're just there for the money, not to help you out. Of course everybody does it for the money in the end, but if they don't give you anything like, "Hey, this is good, but unfortunately this part is going to take longer, it's more difficult, we don't know" — that's where I'd get into conversation.

It also depends on circumstances, but if you're talking to an agency and a senior guy sells you the story, but later on you're only talking to that one person instead of the whole team, that's also a massive negative sign from both sides — that person becomes a gatekeeper, and the engineers don't understand firsthand what's happening, they just hear from somebody who isn't feeling the pain. For me that's an even bigger red flag — you don't need to talk to engineers all day, but if you don't have access to them at all, there's something shady there, keep an eye out.

Another thing I really hate is the "hourly blend" — giving you the hourly rate right away without knowing your problem, without knowing you, without knowing anything. It's like getting in a taxi without a destination — who knows how much it'll be in the end. There needs to be some talk, some coordination, some understanding, because if I give you a pricing list day one, I don't understand your problem. So overall, the biggest cost, the biggest problem, is the partner, agency, or developer who does not disagree with you — that's the most expensive mistake you can make. If you get a yes-man, it's going to be expensive regardless of what happens.

[09:02] Sophia Matveeva: I'd actually encourage listeners to go back to the episode I did a couple of episodes ago — the Calendly case study. Calendly was built by a non-technical founder with an outsourced development team, and he said he interviewed a bunch of development firms and kept coming across yes-men who said, "Yeah, yeah, we'll build all these things." The one he picked was a firm that asked him about the vision — what are you building, what problem are you really solving, what are we doing here. He thought, "Okay, these guys actually seem to care, unlike everybody else." But when he started working with them at their kickoff meeting — he went to see them, they were based in Europe — he apparently left thinking, "Maybe I shouldn't do this." He left discouraged, because they said, "If we're going to do this, we need this and we need that," and he saw it was a far more complicated project than he thought. Thankfully he went ahead, and I absolutely love using Calendly — but that's an example of dealing with a team that's honest with you, not just, "Yeah, yeah, give me the brief and we'll do it."

Once a founder has an outsourced team, how can they tell if things are going well, if they can't read the code?

[10:34] Vuk Nikolic: That's an amazing question, we hear it all the time. I'd say — I know it's kind of obvious — but they need to "pick tech," they don't need to "do tech." I mean, with Claude and ChatGPT they can ask questions now, but to get a sense of how the process works, what's happening, what the bottlenecks are — what I've seen is founders saying, "I have an outsourced team, I'll just focus on the business," and I'm honestly not okay with that. Just as engineers should be aware of what's happening on the business side — sales, marketing — the founder needs to be aware of what's happening on the tech side, especially early on when one founder is doing everything. That could mean daily, weekly, or monthly meetings, just to understand what's happening, what you're frustrated about.

A lot of times founders have this big idea, engineers start building, and meanwhile founders pivot twenty times, do something differently, find some other opening in the market. If you don't talk to your engineer, they'll keep building the original thing — not what you're actually selling now. It also helps engineers understand your mentality — like, "Sophia's the kind of person who'll try to find any angle, so I need to keep my doors open," versus, "This is it, let's go that way." I've seen it a bunch of times where a brief gets handed over, founder goes off doing sales, and two months later they're on completely different pages.

Another thing that's really needed — and I've seen this firsthand — is founders having access to all the systems. I'm not saying be a micromanager, you don't need to live in GitHub or Jira. But have access, because circumstances change, and sometimes at a crucial meeting — a due diligence call, say — you don't have your engineer right there, and it's great to be able to show something and ask Claude to help you out.

The last bit — I took this from the Basecamp guys, 37signals — I really like their "hill chart" approach: everything you do, especially in tech, has an uphill and downhill moment. When we start, especially if I'm not from your market, it's uphill — I need to understand your processes, how you think, how you work. So the initial phase is slower, because we're going uphill. Then, when everything clicks, we go downhill — faster, like skiing. The first 80% is extremely slow, the last 20% speeds up because now we know each other, we know the market. So be patient initially — we as engineers are general-purpose, we could be building something for dentists, trucks, sports, whatever — it's general, so I need to understand your angle to be more productive. So: be transparent, talk to your team, they should talk to you, they should report problems. If they don't report problems, that's a red flag — every time you code something, it's a trade-off, there must be a problem, you just need to be aware of it.

[13:55] Sophia Matveeva: Long-term listeners will have heard this example, but not everyone is a long-term listener — I had this issue with my first tech company, when we got user feedback that people wanted a video feature. I went to the CTO and said, "We need this video feature," and he said, "Okay, we could build it, but if we do, we'll be working solidly on this thing for six months and not on anything else at all. If you think this video feature is the key to success or to fundraising, let me know and we'll drop everything — but I just want you to know this is the trade-off, is this a trade-off you're happy with?" I was so glad he told me that, because I thought, "Yeah, it would be kind of cool, but there are more important things" — and once he told me the cost, it wasn't even in the top five priorities. It's a bit like you have to learn the value of a dollar with your developers, and understand as a founder what you're actually asking for.

[15:00] Vuk Nikolic: I have a similar example — many years ago, a founder, a doctor but also tech-minded, we built a pretty massive platform, self-diagnosis and so on. He wanted, from his eyes, just a "report button" — press one button, generate a report for all patients over ten years, "we already have the data." Making that report was, at the time, at least a year of work. He was like, "It's just a button, you did everything else, how can this take a year?" I broke it down into pieces and details — this is how long each part takes. He said, "Well, okay, we could do it manually then" — but for several weeks that was the main thing we needed to do. Like I was saying, just be honest and transparent: "Of course we can do it, it's going to take a while, meaning it's going to cost you." So be careful about those things — transparency is key.

[16:28] Sophia Matveeva: Speaking of costs and budgets — this is literally the question I get most: how do I know what to pay, how much is my thing going to cost? I'm assuming everyone asks you that too. So let's talk budgeting. Say somebody has tested their idea the way we teach — created a prototype with AI, asked people, got feedback, learned what the feedback really means, not as a salesperson but as an anthropologist. They've now got a tested prototype and want to call developers to build it. How much is it going to cost them?

[16:28] Vuk Nikolic: That's the second question I get, which is normal of course. Everything in engineering, it depends — but the good thing about AI and prototypes, I encourage everybody to try it, because for us as a company it's great when you get those prototypes, it's much better than a founder talking to a designer and getting some rough wireframes. This is the actual thing — "Hey, this is how I'm looking at this." We keep joking, we recently got one that wasn't even a prototype, it was heavily developed and fully vibe-coded, and even that founder joked it was the best specification we ever got, because you can trace it apart, see what's happening.

Regarding pricing, I'd split it into three brackets — everything depends on engineering, but in general — if you're doing something like a smaller tool, some automation connecting a few things, a business process, that's usually between fifteen and forty thousand dollars to make a small business tool that's actually usable. The next tier is building a SaaS — a proper platform, not a one-off tool, something actually used and used — those brackets are more like forty to eighty thousand dollars, ballpark, depending on the use case. The third bracket is something like live streaming, some hardware included, more technical, not a typical B2B thing — that's eighty to one hundred sixty thousand and above.

Why they vary is complexity. I can give a bad example from ourselves — with one team, we thought it was the first bracket, a small tool, but my mistake was I was from the industry so I thought, "Yeah, it's fine, we'll work through it." What happened was the founders had way more details, way more things they wanted, than my understanding. My mistake was not doing the discovery and understanding their needs properly, so we ended up in the second bracket. The moment I realized we were going over budget, I talked to them and said, "Guys, unfortunately there was a misunderstanding, we need to make a call," and luckily we lowered the scope to get close to budget. But that conversation needed to happen. That's why I'd always recommend — I know it's not popular — keep at least 30% of the budget aside for just-in-case situations, misunderstandings, things not said, everyone wanting to move fast and being optimistic. It's not meant negatively, it's more like, "I want to help you, I didn't know everything." These numbers aren't just ours, they're the general ballpark across a bunch of agencies and dev shops I know.

[19:48] Sophia Matveeva: The thing about adding 30% on top — that's just good advice for anything done around your house too. I've decided to embark on an ambitious gardening project, calling in people to level land, cut trees, and so on, and I know once they start, the price is going to grow — not because they're dishonest, but because we'll discover things along the way that need doing, and I'll get new ideas and think, "This is going to be the gardens of Versailles by next year." You always need that extra budget. Also, I've never once seen an MVP go out on time — throughout my career, mine or my clients' — never released on the date we originally thought. Have you ever seen that happen, or should people just always expect it to be later than planned?

[20:57] Vuk Nikolic: Always count on that. Things come up, but I think it's actually good to have a date, so everyone's chasing something — if it's "when it's ready, it's ready," it'll be way longer. But yeah, all of them get delayed. In two cases we had a fixed marketing event — not a feature scope, but an actual event we needed to nail — and that's when we did everything possible to hit the date, though a lot of trade-offs were made. I don't know a situation where "let's do this in two and a half weeks" actually took two and a half weeks — it's always three weeks. Just the nature of the beast, unfortunately.

[21:41] Sophia Matveeva: If you're in a situation where there's going to be an event, or you've got enough money to last six months, don't speak to developers, hear "this will take six months," and think you're fine — that's not a good idea. Work toward the deadline, but plan your projected MVP release to be well before the actual deadline, knowing you're going to slip. I've certainly been in situations where I told an investor, "By the time I speak to them next, we'll have this new thing released" — it's not released, and I'm going to have to ask them for more money. So guys, we've really got to get on it.

[22:27] Vuk Nikolic: One thing I've seen a bunch of times — there's "code complete," meaning the developer just finished that feature, and there's everybody being aligned that it's working, deployed, everyone's aware, marketing is out. Sometimes that deadline doesn't mean "I'm done coding" — it means it's coded, tested, deployed, marketing's aware, business development is aware, we're live, email sent out — not just, "Hey, I'm done." There's a big difference between the two. And as friendly advice — as an engineer, we take briefs literally as written. "Go live is the 5th of September" — September it is. It's not "everybody's go-live," it's mine. So you need to be really detailed about expectations. We at Hurricane got burned twice by that "whose deadline is the deadline" issue.

[23:34] Sophia Matveeva: This is one of the things we really emphasize in our courses — a lot of the problems that go wrong when creating new products and working with developers, outsourced or not, aren't actually about technology. It's usually communication — and not even people using words you don't understand, it's literally, "What does this deadline mean? Does it mean you finish the work, or that everybody finishes all their work that day?" Those are different things. Does it mean we finish testing, or have we even thought about testing? The biggest misunderstandings come from the two sides not asking each other enough questions, thinking they have a clear idea, and then getting to the release event and realizing they never actually had that proper conversation.

Let's return to budgets — say a founder comes to you with a tested prototype, you give them a budget, and they say, "Absolutely not possible for us." What could they do to bring that budget down?

[24:50] Vuk Nikolic: What always drives the budget is actually the scope, not so much man-hours. We've seen it a bunch of times at Hurricane where a founder reaches out and the "MVP" is actually version twelve, not version one — that's the biggest cost, because of course it's your baby, you want everything. Usually it's, "Let's see what can actually be sold right now — the minimal thing you can sell," not everything. Like the example I mentioned where we blew the timeline because things kept popping up — that's the biggest cost driver.

Also, what's helping these days is that coding itself was never the hardest thing — engineers can code, and now with AI it's faster. The biggest problem is actually judgment and accountability. If you're just looking for a "coding monkey," fine, someone will code it — but the price there is judgment: who's going to say, "No, this isn't good, the order isn't right, this is technically wrong"? What I'd do — same mentality as talking to marketing or PR agencies — if it's over budget, let's see what can we do with this budget, is this acceptable or not. Maybe you thought you needed a team of seventeen, but you actually only need two people. Just try to communicate, because on the other side is a business person too, most likely running the company, thinking, "Let's see what's doable."

We've seen a bunch of times founders don't have "our" budget — "This is what I have" — and we sit down and figure out how much we can help. It's never set in stone. We can talk about it, see what's doable — maybe you just need a small push to get your AI prototype to production, or maybe it's a massive thing. That's why with every startup we start with — literally all of them — we do a small discovery process, a few days up to a week, just understanding what you actually need, what you actually have, and mixing the two, because sometimes you've built more than you need, or the scope is genuinely big. So communication needs to happen, and I wouldn't discourage someone with a smaller budget right away — have the conversation, be honest, "I get it, you said forty, we have twelve, what can be done with twelve?" Maybe it turns out to be a weekend project, and you take it from there.

[27:29] Sophia Matveeva: One of our students came to you — I'm hoping you'll hear from her in the next few episodes, she's currently busy because she just had a baby, but she's also releasing a product. She went through the process — had an idea, tested it, created something with Lovable, tested that with a bunch of people, and had a very basic early version. We sent her to you to look at what was going on and give advice. What did you find, and what was your advice? A lot of people are going to be in her position when they come to you — they've built something with no-code tools like Lovable, and now they're thinking, "Maybe I shouldn't release this to everybody before a professional looks at it."

[27:29] Vuk Nikolic: We had a conversation recently, and it's actually one of those examples where I wasn't sure what to expect from Lovable, because the idea itself wasn't that basic — a lot happening in the back end. She gave me access to Lovable — the good thing is it was already connected to GitHub, so I could see all the changes, and Supabase, so I could see the database. Everything was set up quite correctly. All the horror stories you hear online about AI messing up stuff — in this case, not true. Not ideal — if we were doing it from day one it wouldn't be the same — but not terrible. Especially for putting it live in production, I think it was quite good, it would pass most of my checkmarks.

What happened was she had a pretty tight deadline, but AI had missed a lot of needed features — I think six or eight, I forget the exact number. That's where she needed help. She also mentioned a more affordable outsourced agency that might help. I was honest with her — for the budget she had, regardless of location, you can't do everything, you have to pick and choose. If you need help, let me know too, because it's your baby, you can't choose all the details for you — let's have a conversation, I know it's a tough call, but with that budget you can't have the whole thing.

What was really positive is that the prototype gave a really good picture of what she wanted, and the code itself was fine — but it was missing some key, not-so-trivial features. Anybody can "vibe code," but the problem is accountability and judgment — if somebody codes without knowing what's happening underneath, it's like me playing plumber with no clue, water on my walls, not knowing what to do. She was about 80-90% done, and it was, "I need help, I got to this point, you can see what I did, I just need a bit of an advisor to get me over the hill." For that initial stage, that was ideal. What happens when it scales — and I'm pretty sure it will — is a different conversation. It doesn't need a rewrite, but changes are obviously needed. So: really good timing, tools are now amazing for founders to prove a concept and even get customers — but when it gets exciting and customers are coming in, get somebody, get a plumber, to check your pipes before you fully put it live with any marketing campaign.

[31:14] Sophia Matveeva: This is what we keep telling people, whether you're working with us or just listening to the show — you have to go through that prototyping and testing process, because that's how you come up with something people actually want. You can get quite far with a tool like Lovable, but don't do anything too serious with it — don't send it to people en masse until a professional has looked at it. Maybe it's a C-plus or C-minus by professional standards — but for a non-technical person, that's amazing, we couldn't do any of this until fairly recently. So carry on as you are, but in a month, once you onboard more people, definitely make changes — or if you've created something that looks nice but is leaking data everywhere, don't wait a month, change it now.

Don't be left to your own devices if you're not technical and experimenting with Lovable, because the risk is too high. And when thinking about risk, think about legal risk too — if you're building a B2B tool and start leaking customer data everywhere, and one of those customers has a well-funded legal department, keep that in mind and speak to a professional. Okay — now that I've scared everybody with getting sued — if a founder only remembers one thing from this conversation, what should it be?

[32:46] Vuk Nikolic: The main thing: if your development partner never disagrees with you, that's your most expensive mistake. That person or agency needs to say, "I don't like this, I don't think this is good" — I mean, you're an amazing founder, but this thing isn't how it should work — that's actually the best comment you can get. If it's a yes-person, that's the biggest and most costly mistake, because you easily slip into "feature creep" — you say you need this one thing, and they say, "Yeah, that's the one thing," and it just grows. If somebody disagrees, but not on absolutely everything — you don't want a hater either — trust your gut feeling when you talk to someone: is this a person I can work with for a year, five years, ten years? If your gut says you don't like this person, say no — there are so many developers out there, find somebody you click with. That's most important.

[33:42] Sophia Matveeva: As you were saying that, I was thinking these are the hallmarks of a normal, healthy relationship. In a healthy relationship — romantic or friendship — it's not just, "Yes, you're great, everything you do is fantastic." Maybe at the beginning, but a long-term healthy relationship has some disagreement — "We've been eating the same thing for two weeks, can we do something else now?" It's how you navigate those discussions that matters. The hallmark of a healthy relationship isn't that people never challenge each other, it's how they do it — and whether you're disagreeing for the sake of building a great product or venture, or just to be difficult.

[34:34] Vuk Nikolic: Yeah — if you want a yes-person, you can talk to Claude, and it'll tell you you're absolutely right about every idea you have. You need somebody who'll say, "No, this isn't a good idea."

[34:44] Sophia Matveeva: That's a very good point. Where could people go if they wanted to learn more from you?

[34:48] Vuk Nikolic: We have our website, hurricane.studio. We recently opened up our "Storm Survival Guide" for non-tech founders — we go through a bunch of the topics we discussed today, MVP costs, how do you know the partner is right, and other details. There are also contact details there — you can book a call with my team, and it doesn't have to be about getting a quote, it can be, "I have this problem," or "I have this agency, not sure about them," or "my partner said this." We love to talk tech, we love to talk about startups, so if you need any help or advice, feel free to reach out through the website — there's a contact form there.

[35:27] Sophia Matveeva: Awesome, thank you very much. Everybody, I've had a look at the blog, there's genuinely useful stuff there. If you're working on something, if you're in the position our student was in — created something with Lovable or whatever, and now thinking "what do I do next" — book a call, because why not, you literally have nothing to lose, so you might as well find out.

On that note, I shall love you and leave you. Thank you very much, Vuk.

Vuk Nikolic: Thank you.

Sophia Matveeva: Wasn't that interesting? This guy really knows what he's talking about when it comes to non-technical founders, which is why I wanted to make sure you learned from him — you're welcome. On that note, have a wonderful day, and I shall be back in your delightful smart ears next week. Ciao.