You Don't Own Your Product Until You Own These 5 Things

The Hostage Situation Nobody Warns You About

You raised a round. You found an agency. You're three months into the build, things are moving, and then something shifts. Maybe the relationship goes sideways. Maybe you want to bring someone else in. Maybe you just want to see the code.

And that's when you discover: you don't actually own anything.

The code lives in your agency's GitHub. The app is hosted on their AWS account. The domain is registered under their admin email. Every third-party service - Stripe, SendGrid, analytics - is tied to accounts you don't have passwords for.

You're not a client. You're a hostage.

This isn't rare. Over the last five years of consulting with agencies and product companies, I've seen this play out with dozens of founders. Good people, good intentions, no technical background - and zero ownership of the product they're paying to build. When they finally want to make a change, they realize they can't. Not without their agency's cooperation.

"If you don't own your code, your hosting, and your domain - you don't own your product. You're renting it from someone who can walk away."

This article is for the startup founder - small team, early stage, probably non-technical - who needs to understand what they actually need to control. Think of it like eating your veggies. It's not glamorous, but it keeps you alive.

The Secure Email Nobody Tells You to Set Up

Before we get to the five critical things, there's a prerequisite that most founders skip entirely: a dedicated, hyper-secured email address that serves as the master account for your product infrastructure.

This isn't your regular Gmail. This isn't the email you use for newsletters and Slack invites. This is a separate account - I recommend ProtonMail for privacy, but any provider works - that exists for one purpose: to be the owner account on every mission-critical service your product uses.

Set it up with every security layer available. Two-factor authentication. Recovery keys printed and stored physically - in a safe, a lockbox, whatever you have. This email address is the equivalent of your bank login. Treat it that way.

Here's the rule: this email goes on critical infrastructure only. Your code repository. Your hosting. Your domain registrar. Your payment processor. Your production database. That's it. Do not use it for project management tools, team communication, or anything operational. The more places this email exists, the more attack surface you create.

If you're using Google Workspace or Microsoft 365 for your company, those services typically require a backup non-service email. This secure address works for that too.

"One email. Hyper-secured. Used only for the services that would destroy your business if someone else controlled them."

The Five Things You Must Own

Every software product - no matter how simple or complex - runs on a handful of critical components. If you don't own these, you don't own your product. Full stop.

1. Your Code Repository

This is where your source code lives. For most startups, that's GitHub. Could be GitLab or Bitbucket, but GitHub is the standard.

The primary account - whether it's a personal account or an organization account - needs to be registered under your secure email and owned by you. Not your CTO. Not your agency. Not your lead developer. You.

If your dev team needs access (and they will), they get added with the correct permissions. Give them write access to the repositories they're working on. They can push code, create branches, review pull requests - all of it. But the owner-level access stays with you.

If you don't know how to set up permissions on GitHub, spend 30 minutes with ChatGPT or Claude and figure it out. This isn't optional knowledge anymore. You don't need to understand every Git command, but you need to understand who has admin access to your codebase and what that means.

2. Your Hosting

This is where your application actually runs - the servers, the infrastructure, the environment that makes your product accessible to users.

For a simple app, this might be a serverless platform like Vercel or Netlify. For something more complex, you're probably on AWS, Google Cloud Platform, or Azure - and the setup can get genuinely complicated.

You don't need to understand every configuration detail. But the ownership account on whatever hosting platform you're using must be tied to your secure email, with you as the billing admin. You need to know where your app lives, what it costs to keep it running, and who has access to shut it down.

If your agency set up the hosting under their account (common - more on this later), that's fine temporarily. But you need a plan to migrate it to your ownership, and you need that plan documented before you're 70-80% through your payments.

3. Your Domain

Your domain name isn't just your website URL. It's the foundation of your entire digital presence - your app's subdomain, your email service, your SSL certificates, your DNS routing. Everything flows through it.

You need to know where your domain is registered (GoDaddy, Namecheap, Cloudflare, Google Domains - wherever). The billing and admin account on the registrar must be under your name, your email, your payment method. Not your developer's. Not your agency's.

If someone else controls your domain, they control your product's identity. They can redirect your traffic, take your email offline, or simply let the registration lapse. This is not theoretical - it happens.

4. Your Database

This is where your product's data lives - user accounts, transactions, content, configurations, everything that makes your application more than an empty shell.

Your database might be hosted alongside your application (on AWS RDS, Google Cloud SQL, MongoDB Atlas, or similar), or it could be a separate service. Either way, the admin account needs to be yours, and you need to understand - at a high level - what data lives there and how it's backed up.

If your agency is managing the database and you have zero visibility into it, you're one disagreement away from losing access to your users' data.

5. Your APIs and Backend Services

APIs are how the different parts of your application talk to each other and to external services. Your backend - the server-side logic that powers your product - typically exposes APIs that your frontend consumes, and also connects to third-party services like payment processors, email providers, analytics platforms, and more.

Worth noting - most modern hosting platforms now handle both your frontend and backend under one roof. So when we talk about "backend services" as an ownership concern, the real risk isn't your server-side code (that's covered under hosting). It's the third-party services your product depends on - Stripe, SendGrid, Twilio, Amplitude, and similar. These are the accounts that quietly become someone else's property if you're not paying attention.

You need to understand the basic architecture: what services are involved, how they connect, and which third-party accounts are in play. Every paid third-party service should ideally be signed up under your ownership. You buy the service. You're the admin. You grant access to your team.

This is the one founders most often delegate entirely and regret later. When you don't own the Stripe account, the SendGrid account, the Twilio account - you don't own the revenue pipeline, the communication channel, or the notification system. You own nothing but a frontend that talks to services controlled by someone else.

"Five things. Code, hosting, domain, database, APIs. If any of these are under someone else's name, you have a dependency - not a product."

The Agency Migration Reality

Here's where things get practical. If you're working with an external agency - especially on a project that stretches beyond 6 months - the initial build is almost always done on the agency's accounts.

This is normal. It's common. It happens because agencies need to move fast in the early phase, and waiting for a non-technical founder to set up and configure a dozen services creates friction that delays the project. Most founders either take too long to respond or find the setup too complicated, so the agency handles it and plans to migrate later.

That's fine - as long as you do three things from day one:

Request an architecture diagram. Before any code is written, ask your agency: "What services are we using, where is each one hosted, and what does the architecture look like?" This doesn't need to be a 50-page technical document. A basic diagram showing the components - frontend, backend, database, hosting, third-party services - is enough. If your agency can't produce this, that's a red flag.

Agree on the migration timeline. Migration should be tied to a payment milestone. The standard pattern: a deliverable is completed, payment is processed, and the agency migrates the relevant infrastructure to your accounts. Get this in writing before the project starts. As we cover in our piece on what product discovery actually is, the right time to surface these decisions is before code - not after a dispute.

Understand that migration is not instant. This is where founders get burned by unrealistic expectations. Migrating from agency-owned accounts to your own is a complicated, time-consuming process. It's not copying and pasting files. It involves reconfiguring environments, updating credentials, re-establishing third-party integrations, testing everything end-to-end, and dealing with external dependencies that don't always cooperate.

Depending on the complexity of your product and how many third-party integrations are involved, a full migration can take anywhere from a few days to two months. If a developer tells you it'll be done in a day and it takes a month, that's not incompetence - that's the reality of software dependencies.

"Migration isn't a flip of a switch. It's a project within a project. Plan for it, budget for it, and don't let anyone tell you it's trivial."

The Third-Party Services Rule

Beyond the five core components, your product probably uses a handful of third-party services - analytics, error tracking, email delivery, push notifications, feature flags, monitoring, CI/CD pipelines. The list grows fast.

Here's the rule: if it's a paid service, it goes through you. You sign up. You own the account. You manage the billing. Your team gets access as collaborators or team members - never as the account owner.

For free-tier services, the stakes are lower, but the principle holds. If a service touches production data or affects your product's functionality, the ownership trail should lead back to you.

The secure email I mentioned earlier? It's only for the five critical services. For third-party tools, use your regular business email. The point isn't to funnel everything through one account - it's to ensure that nothing critical is owned by someone who might not be around in six months.

What Happens When You Don't Do This

I've personally worked with founders who discovered - mid-project, mid-dispute, mid-pivot - that they didn't own any of the infrastructure their product ran on. The conversations always follow the same pattern:

"I had no idea the GitHub was under their account."

"I thought I owned the domain - turns out it's registered to my old CTO."

"The agency says they'll hand everything over, but only after I pay the final invoice."

"We want to switch providers but we literally can't access the server."

These aren't edge cases. These are Tuesday for anyone who's consulted in this space long enough. And the common thread is always the same: the founder trusted someone else to handle the infrastructure and never asked questions about ownership.

This is especially dangerous when the relationship with your agency or technical partner goes south. If they hold the keys to your code, your hosting, your domain, and your data - your negotiating position is zero. You can't fork the code. You can't bring in another team. You can't even see what you've paid for.

The entire Biz of Dev model is built on the opposite principle. Everything we build, our clients own from day one. Code, design, infrastructure, documentation. No vendor lock-in. No hostage situations. That's not a marketing line - it's an operational decision that protects founders from exactly the scenario I'm describing.

Here’s Our Take

This article isn't about bashing agencies. Plenty of agencies handle ownership transitions professionally and transparently. This is about the pattern I've seen too many times to ignore: founders who pour money into building a product they don't technically own.

The fix isn't complicated. One secure email. Five accounts under your control. An architecture diagram requested in week one. A migration plan tied to payment milestones. That's it.

You don't need to become a developer. You don't need to understand Kubernetes or DNS propagation or GitHub Actions. You need to understand ownership - who holds the keys to the things your business runs on.

If you're a non-technical founder reading this and realizing you don't control any of these five things - don't panic, but don't wait either. Start the conversation with your team today. Ask for the architecture diagram. Ask whose email is on the hosting account. Ask where the domain is registered. The answers will tell you exactly where you stand.

And if you're about to start a new build - with any team, not just us - make this the first thing you sort out. Before the first wireframe. Before the first line of code. Before the first payment.

Because you can always rebuild a feature. You can always redesign a screen. But if you lose access to your infrastructure, you lose the product.

"You don't need to understand code. You need to understand ownership. One protects features. The other protects your business."

How to Protect Your Product Before Writing a Line of Code

Owning your product infrastructure isn't a technical task - it's a founder task. The five components - code repository, hosting, domain, database, and API/backend services - are the foundation your entire product sits on. If any of them belong to someone else, you're building on borrowed ground.

Set up the secure email. Claim ownership of the five critical services. Request the architecture diagram from day one. Tie migration milestones to payments. And treat every third-party paid service as something that flows through your account, not your agency's.

This is the boring work that saves you from the catastrophic conversation. Do it now, while things are good - not later, when they aren't.