306. From prototype to product: the infrastructure trap non-technical leaders miss

If you have a working product - well done. This truly is a major milestone.

BUT maintaining commercial control of what you've created might be challenging. 

In this episode, we contrast two founders: Founder 1, who has a no-code prototype ready to scale, and Founder 2, who let an outside agency manage her hosting and was hit with a $4,000 bill just to try and claw back her own data. We break down why legal ownership on paper means nothing without operational control of your code and servers.  

• The illusion of progress: Why a functioning app doesn't automatically mean you own a secure business asset.
• Prevention vs. cure: How to use the prototype phase to lock down your infrastructure before hiring developers.
• The $4,000 gate fee: The hidden financial liabilities of letting an external agency manage your cloud accounts.
• The 3-point audit: Crucial steps to verify who controls your GitHub, cloud servers, and documentation. 

Secure your tech asset

Don't wait for a surprise bill to find out who holds the keys to your technology.

If you want an independent review of your prototype or current development setup, book a Technical Diagnostic with us. We don't sell development hours; we give you an unbiased evaluation of what you control, what needs fixing, and what it should realistically cost. 

Timestamps:

• 00:00 - Introduction: When you don't actually control your own tech
• 04:00 - Founder 1: Built a working prototype, now what?
• 06:00 - Why a technical diagnostic must come before hiring developers
• 09:14 - Founder 2: Real product, real users, but a dangerous hidden problem
• 11:37 - The $4,000 wake-up call: Legal ownership vs operational control
• 14:01 - The GitHub analogy: Why admin passwords matter
• 16:12 - Three things every non-technical founder must audit right now
• 18:32 - When compliance laws kick in and why this becomes urgent
• 20:52 - Closing and resources

Free AI Mini-Workshop for Non-Technical Founders:

Learn how to go from idea to a tested product using AI — in under 30 minutes.

Get free access here: https://www.techfornontechies.co/aiclass

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 a review or 5-star rating over 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:00] Sophia Matveeva: Imagine if you built an app and people love it. You have happy paying customers and you are growing. And then you decide to switch development teams, and then you realize that you don't actually control any of your tech infrastructure. Now, if you know what that means, you know that's a bad thing. And if you don't know what that means but it sounds menacing, you're right. It is. So listen to this episode to find out why this happens and what to do if it has happened to you.

[00:00:31] Hello and welcome to the Tech for Non-Techies podcast. I'm your host, Sophia Matveeva. If you're a non-technical founder building a tech product or adding AI to your business, you're in the right place. Each week you'll get practical strategies, step-by-step playbooks, and real-world case studies to help you launch and scale a tech business without learning to code. And this is not another startup show full of jargon, venture capital theater, or tech-bro bravado.

[00:01:03] Here we focus on building useful products that make money without hype and without code. I've written for the Harvard Business Review and lectured at Oxford, London Business School, and Chicago Booth. So you are in safe hands. I've also helped hundreds of founders go from concept to scalable product. And now it's your turn. So let's dive in.

[00:01:32] Hello smart people. How are you today? Today I am feeling victorious. Yesterday I had a new air con unit put in in my house, and it was supposed to take two hours, and it ended up taking six hours. And so that's why I feel victorious. Finally, it was a long battle. I live in a house with really thick walls, and the initial quote completely underestimated the reality of my actual house, which is actually related to this episode. Something might look simple and easy at first glance, and then when you start doing the work, then it becomes this whole big, long, expensive thing.

[00:02:14] So today you are going to hear lots of lessons from two founders. I'm going to tell you about two founders who came to our CTO question and answer session last week. We had a CTO QA session last week because we now have a fractional CTO with 20 years' experience working with us. And we held a session where you could come and ask him your questions. And if you're thinking, my God, this sounds amazing. Why did I miss that? Well, it was amazing. It really was actually really useful. And you missed it because you're probably not getting my excellent emails. I don't announce everything on this podcast because basically I don't necessarily always have the time. So if you want to make sure that you don't miss another QA with our team, then make sure that you are signed up to my very excellent emails. And you can sign up at techfornon-techies.co.

[00:03:12] Okay, let's begin today's lesson. You are going to hear the stories of two founders who came to the QA and the questions they were asking. And so this will be what you can learn from these, from their answers, what you can do to prevent some of the mistakes that they've made. And also for the people who came, thank you. I really, really appreciate you. I know that some of you listen to this podcast. And so this is also going to be a refresher for you for those who came, you know, a kind of a good summary of what you have learned. And remember, if you came and you're listening to this episode and you're thinking, this isn't about me, you might be about you next week because we're going to have a follow-on episode about this. But also learning from other people and hearing what they're working on actually makes you a better innovator.

[00:04:00] Founder 1: Built a working prototype, now what?

All right. So let me tell you, and obviously I'm not gonna mention any names because that would be unprofessional. So I'm just gonna call people Founder One and Founder Two. So let me tell you about Founder One. Founder One has built a working prototype using no-code tools and AI tools. And she's really proud of it because she put it together using some of the old school no-code tools, you know, spreadsheets, Airtable, Zapier, and so on. And the thing that she has created, it functions and it does what she wants it to do. And so she's proud. Naturally, I'm very proud of her too. And now she is thinking about, okay, well, if I am to take the next step, what am I supposed to do? So if this is going to be a commercial thing, what do I need to do? If I need to add robust features, acquire paying users, if I want to scale, or you know, even if I want to just have one user using it, but they're going to hold sensitive data in it.

[00:04:50] Like, what needs to happen to this product? And so she's thinking, do I need a developer? What would the developer actually do? How long would it take? How much should I pay? How should I set up the task? And these are exactly the right questions. And our honest strategic answer is that nobody can give you a proper quote and basically a proper timetable without looking at what you've actually built and also understanding your commercial vision. It's like going to the doctor, you know, when you're like, well, you know, I've got a bit of a headache and, you know, I've got some aches and pains. Like, can you give me the prescription? Well, no. If you want proper treatment, then you should go for a proper checkup. You might get referred to another specialist. And you know, since we accept this in healthcare, it is the same in product development.

[00:05:44] So when you have built your product with AI and no-code tools and you've already got market feedback, so this is the first stage of what we actually teach in our program, we teach you to build a product with AI no-code tools and then go out to the market and find out whether people want it and whether they would pay for it. After that, we recommend that you work with developers, but those developers essentially need a roadmap and some instruction from you about what on earth you're doing. So at this point, what I would recommend you do is you get an independent technical diagnostic first.

[00:06:00] Why a technical diagnostic must come before hiring developers

A developer needs to review your specific product architecture. So what is it that you've created? Whether it's just created on one tool, like you've just done the whole thing on Lovable, or like this founder, it's a whole bunch of things together. They basically need to see, like, what have you made to see where the vulnerabilities are. But also don't just think of it as a technical thing. Because when you are actually thinking about building something commercial, building something that you would charge money for, then you also need to think about the business side. So you need to map the technology with your innovation goals. So you need to answer questions, you need to work with somebody who's going to help you answer questions like, what kind of venture are you building? Do you plan to raise institutional capital? Are you going to raise any capital? How many customers do you want to reach? Do you want this to be a big scalable global tech company, or do you want it to be something that you have created maybe for your current customers?

[00:07:12] So the answers here are going to determine essentially how much you're investing, the outcomes you expect, and also they will relate to your tech architecture, right? Because if you're building a skyscraper, you obviously need different architecture to if you're building a two-story building. And so this is to say that technology and business strategy are very, very interconnected. So if you are in the place of Founder One, then that's your perfect window to basically get this diagnostic where you align your business strategy with your tech needs and do that before capital execution. If you do that, then actually you're going to be really, really set up for success. Because right now, if you are in the stage of Founder One, you're basically at a clean slate. So Founder One, she is at the ultimate position of power to set up her own infrastructure and to dictate the rules of control before any outside developers come in and basically rush you and basically confuse you.

[00:08:22] By the way, I didn't tell you about this before, but we have actually started offering this kind of diagnostic session to our listeners and to our newsletter subscribers. So basically what you would get is if you have created a no-code thing, because I know so many of you have created stuff and now you're thinking about, well, what do I do? What we could do for you is we could essentially work with our CTO to look at the thing that you have done to see, okay, which vulnerabilities need to be taken care of right now, what needs to be taken care of but it can wait, so you don't need to invest in it right now. And how do we align this architecture with your broader vision? So if you want to have this diagnostic session, which if you have built a no-code thing and you basically believe that, okay, now it needs to become a commercial product. I highly recommend you book this diagnostic session because I actually don't run a development shop. So my job is not to sell you development hours. It's basically to give you the best possible advice for what to do next. So if you're at this stage, then definitely book a call with us. And the link to do so is in the show notes.

[00:09:14] Founder 2: Real product, real users, but a dangerous hidden problem

Okay. So this is Founder One. Now let's talk about Founder Two. So Founder Two is actually further on than Founder One. So Founder One, we can say is at the prevention stage. She is at this perfect stage where she has done everything right so far. And now this is when big expensive mistakes can happen, but they don't have to happen if you set things up correctly. Founder Two is at a later stage of the journey. So Founder Two skipped some steps. And so I'm gonna tell you about what the situation is. So Founder Two has created a product, and she created a product that people love. Like it's a real success story. So she first did the no-code validation, then she hired a development team. She's got a real product with real users, people are paying for it, she's got fans, she's got customers, like the whole thing. It's really, really good. She's still in the early stages, but she's basically got the core makings of something amazing and something that can basically scale globally. So she's basically doing really well. But there are some issues.

[00:10:26] She came to our CTO QA with a very specific question. Should I migrate my product to my own infrastructure or let my developers keep running this infrastructure? So what does it mean? Basically, it means that on paper, Founder Two legally owns her product. So the IP is hers. She's got this legal contract. The intellectual property all belongs to her. But in practice, all of the intellectual property, basically all of the code, all of the back end code and the front end code, they're basically sitting inside her developer's private cloud account. And she's working with a development shop as opposed to just having somebody working for her in her own team.

[00:11:37] The $4,000 wake-up call: Legal ownership vs operational control

So when she said, okay, well, if I were to stop working with you, what would it look like? What would it look like to basically take all of my infrastructure out of your system? And they said that it would take four thousand dollars just to basically begin scoping out the migration. And they didn't even include the actual technical work to move the files. And this basically, when I heard this, I was thinking, hang on a second. This just does not sound right. This sounds really quite dangerous. Our CTO had exactly the same reaction. We also actually had an attorney on the call who's building her own thing, and she was also like, hang on a second, this is really scary. So we all basically said, you don't want to be in this situation.

[00:12:24] So what happened was that Founder Two didn't realize that by letting somebody else manage the infrastructure under their name, basically in their account, she was creating a problem. And she did this because she didn't know about the difference between legal ownership and operational control. So you can have all of the legal contracts in the world, but if you're not actually going to enforce them, if you, you know, don't have the money for a big legal battle or don't have the time for a big legal battle, it almost kind of doesn't matter unless it's criminal law, then that's a whole different thing.

[00:13:00] So in this example, let's imagine your developers basically hold all of your code in their GitHub accounts. GitHub, if you don't know, it's basically like this. It's kind of like where developers keep their portfolio so we can see developers' work, but it's also where they actually keep the code that they've written. So it's like where they store all of their work. So if you own a company, you would have your own company GitHub account. And when a developer joins you, they would join that GitHub account and then they would write code in that. And then when they leave, you know, it kind of doesn't matter so much that they leave because you keep your GitHub account. It's basically like, you know, somebody gives their company email address and they have access to your own Google Drive. It's basically kind of similar, not the same thing, but it's kind of similar.

[00:14:01] The GitHub analogy: Why admin passwords matter

Now, in Founder Two's case, the issue was that her outsourced development firm held all of her infrastructure on their own account. So even though she technically owned it, how would she, especially as a non-technical person, get it out of their own account? It would be basically possible. So if you don't hold the admin password, if you do not hold the admin password to your servers, you're essentially renting your own product from your developers. And that is a scary thing. And the longer you leave your stuff in their warehouse, the more expensive it gets to take home. And this kind of thing happens in tech and outside of tech. This actually happens to corporate executives and established business owners in all sorts of different environments because legal ownership and operational control are different things.

[00:14:58] So what I want you to know is that as a business leader, you need to treat your software exactly like you would commercial real estate. So you wouldn't let a building contractor hold the only set of keys to your corporate headquarters, right? So like let's imagine that somebody's built your corporate headquarters. You own it, you wouldn't just be like, yeah, okay, you hold the keys and all the passwords and IDs, it's totally fine. No, you'd be like, no, no, I, even if I'm not using it all the time, I want to own that stuff. So if Founder Two had had some sort of diagnostic to really actually look at the contract she was signing and to look at how things were being set up at the stage where Founder One is at right now, she would not be in this situation.

[00:15:48] And Founder Two is very, very clever. She's really, really brilliant. So this is not to say that she, you know, she ended up in this situation because she is a first-time founder. She's a first-time non-technical founder. And if you're a first-time non-technical founder, you're basically kind of vulnerable. And when you're vulnerable, some people openly take advantage of you. And some people, which is what I expect happened with her developers, some people just do the thing that's easiest for them, which is not necessarily easiest for you. Maybe they're not, you know, intentionally taking advantage of you. But what ends up happening is that they did the thing that was least difficult for them, which then means that you have to pay to sort it out.

[00:16:12] Three things every non-technical founder must audit right now

So here are three things that every business leader, every non-technical founder must audit right now to make sure that you have control and not just paper ownership. So number one, your code, where does it live? Is it sitting in your corporate GitHub account or in somebody else's? Answer this question. If you shut down tomorrow, can you still download your code and then do something with it? That's number one.

[00:16:58] Number two, your infrastructure. Who controls the actual cloud service? So whether it's AWS or Azure, whatever, like who's got the passwords? Who is accessing this stuff? Do you have that information? And yes, if you're not technical, if you had the passwords and you didn't know what to do with them, that's totally fine. But as long as the passwords are linked to your email address, then you can get another developer who can access all of that information on your behalf, then you're in control. Another question, are the billing and master admin accounts in your company's name as opposed to somebody else's name? Because if they're in somebody else's name, it's going to be really, really difficult to prove to say AWS or Azure that this is your stuff and it belongs to you.

[00:17:44] And number three, your documentation. If your developers disappeared tomorrow, is the thing that they have created documented well enough for another developer to take over seamlessly? If not, then again, you have legal control, but operationally you are pretty much stuck. So think about these three questions. If you want to look at the transcript for this episode to just get those three questions, get those three pillars, go through the questions and answer them. But what I would recommend much more is if you actually just get this diagnostic session with us, then we'll be able to tell you where your vulnerabilities are, how serious they are, and what you can do about them.

[00:18:32] When compliance laws kick in and why this becomes urgent

So figuring this stuff out, you know, if you're at the really, really early stages and you're listening to this and you're freaking out, like if you haven't done anything, then don't worry about it. If you haven't done anything, just get moving. But if you're at the stage when you're about to start charging customers, this is the time to worry about this stuff and take some action. Because the second a dollar changes hands, you're handling payment data, you're handling personal information, you're also handling sensitive user metrics. Compliance laws like GDPR start applying. Security vulnerabilities become your personal and legal financial liability. This is why we really want to understand who owns what, where is it held, how secure is it? Is it yours? Is it somebody else's? This stuff, okay, might sound a little bit like boring and legal, but when you get sued or lose access to your product, it is not boring.

[00:19:38] Anyway, the point is whether you're moving from a prototype to a market ready product like Founder One, or discovering mid-build that you have some issues, like you don't fully control your assets like Founder Two, the strategic answer is the same. You need professional, independent, expert eyes on what you have created and on your contracts if necessary, before your mistakes get incredibly expensive. And as a non-technical founder, of course you're making mistakes. Of course you're learning by doing. Even if you were a technical founder, you would still be learning by doing. This is what this journey is. So don't feel bad if you're making mistakes. And you know, if I'm telling you this story about these founders, don't think, I would never do that. Well, you know what, you probably would. If you're doing something for the first time and it's in a domain that is not familiar to you, of course you're gonna make mistakes. This is what happens, and this is why expert guidance is basically your answer.

[00:20:52] Closing and resources

So if you're listening to this episode and you're realizing that you're not 100% sure whether your company holds the master admin keys to your code and to your servers, then stop guessing. At Tech for Non-Techies, we offer this independent technical diagnostic session, which I could not recommend enough. So as I told you, we do not sell development hours. So our only job is to give you our unbiased, expert, executive evaluation of your vulnerabilities, what you control, what needs to be fixed, and what your next step should realistically be and how much it would cost. So I highly recommend that you book it so you can protect your commercial assets before things get expensive. So click the link in the show notes right now and book a call to see exactly how this diagnostic session would work for you. And on this note, my dear smart people, I will love you and leave you. Have a wonderful day and I shall be back in your delightful smart ears next week. Ciao.