What do you need to know before building a tech startup in 2025?

Quick answer: before writing any code, validate the idea (a landing page collecting real email signups is a stronger signal than a friend saying "that sounds cool"), build a minimum viable product that doesn't need to be real software, then choose a tech stack based on developer availability rather than novelty, and build DevOps and CI/CD practices in from day one so scaling later doesn't mean a costly rebuild.

Software development is expensive, so before we go into that let's talk about everything you need to know before you start developing software.

1. Idea validation

Before you spend a day, a week, a minute, or even some pound notes on your new idea, it's vital that you get it validated first. Sounds obvious, but so many people skip this step. You need to know that somebody else is actually going to find your idea useful. How would you tell somebody about your idea without worrying they'll run off with it? Well, they're not going to run off with it — execution is very, very hard, and as we get into this you'll find out how hard that is.

Telling people what your idea is — if they go "oh yes, that's amazing," that's validation. It's not "oh, I'm going to go do that myself," because that's really hard to do, as we'll get into. So tell people what your idea is and gauge their reaction: is it interesting, do they find it interesting, or do they just shrug? You need to ask a lot of people.

Two good ways of asking: have a landing page. The landing page should say "here's a service or product I want to offer, would you be interested in it — give me your email address." You'll be surprised how hard it is to get email addresses off people, even if they like you, so if they sign up off a page like that, that's a very strong validation signal. Other options are market research techniques, like looking at Google Trends and keyword research — are people even looking for the idea you've had? If they are, you'll see evidence of that.

Of course, the strongest evidence is somebody already doing it — are there competitors in the market already? This isn't necessarily a problem. How many times have you gone down a high street and there've been four restaurants all on the same street? That's fine — they all offer something different while being in the same place, but they're basically offering the same product: food. If your idea is related to food, maybe it's a new restaurant offering Indian food with some Japanese influence — you get the point, there's already going to be competition in one way or another related to your idea.

If there isn't any competition and you can't find any, I'm sorry, that's not validation — that's probably a bad idea. Somebody's probably tried to do it before, lost a load of money, and that's why you can't find any evidence of it. So look out for competition. Once you've validated your idea with some Google Trends research, some keywords, a landing page collecting email addresses, and checked whether there are any competitors out there, the next thing you need to do is build a minimum viable product (MVP).

2. Minimum viable product

An MVP doesn't necessarily need to be any software whatsoever. I've seen minimum viable products that were on a notepad — just enough to give the illusion of what the app could do. If you're talking about an app that identifies pictures as you upload them, you can probably mock something up pretty quickly that doesn't actually work but gives the illusion that it's working. Again, this is just to get people to validate your idea. By having the landing page, the wait list I mentioned earlier, and an MVP, you should get a pretty good idea of whether you're going to have enough people interested in your idea to make it worthwhile. It's worthwhile even if only one person wants it, but it's a lot of effort to go to for just one person.

3. Technical foundation

So we've got the idea validated, hurrah, and we know what our MVP should look like — let's talk about the tech stack. What I mean by a tech stack is the technology you and your developer team are going to put together. If you're a developer, you'll probably already have a good idea of what that should look like; if you're not, I've got another video on tech stacks for startups I'll link in the description. Essentially it needs to be something where you can find a good supply of developers — there's no point going for something obscure. You'll find it easier to hire Python, PHP, or JavaScript developers than, say, COBOL developers — they exist, but they're harder to get hold of, and if they're harder to get hold of they'll be more expensive, and as a startup, costs matter.

Next up is infrastructure decisions. Infrastructure needs to be supportive when you're small and supportive when you're big, to give you room to grow — the best thing about startups is scaling up, but you want to scale in a way that doesn't cost an arm and a leg and stays easy for your developers and infrastructure people to change. If you start small, you can start off with something like serverless or very small servers that don't cost you very much, then scale up to bigger servers or different technologies as you go. Depending on the technology stack you've chosen, this can be easier or harder, but it's another consideration for scaling — you don't want to spend a ton of budget re-architecting the entire infrastructure just to get a little bit bigger, so have a little forethought before you even get started.

Your scalability considerations should cover: how many users do you expect to have, and how many simultaneous connections do you expect? Both will tell you how much scale you need. And because I'm in DevOps and operability, I wouldn't go very far without saying you need a DevOps pipeline. Some of my customers use a DevOps pipeline to test and build their new release, then use another pipeline to deploy that release to the production servers, with testing on the test servers along the way — all automated so it just relies on a button press, empowering them to release when they need to without relying on someone else to hand off the deployment. All this saves you time and money.

4. Development strategy

You've probably heard of Agile methodology. What that means is you don't know all the answers when you start — simple as that. One of the Agile principles is "we value working software" and use that as a definition of progress; there are 11 others, you can look up the Agile Manifesto. Because we don't know exactly where we're going when we start out, we just know the direction we're travelling in, our MVP.

Then there's sprint planning. A sprint is a way of breaking up work — you don't necessarily have to use sprints in the initial stages if you don't want to, but you've probably heard of a kanban board or to-do board: what needs to be done, are we doing it, and has it been done. It's a visual representation of the amount of work currently being done (you don't want too much of that at once) and what's actually been done, which you can celebrate. Sprint planning just goes one stage further and says we're going to pick these items and do them in the next week or two, however long the sprint is, and at the end of the sprint you can see how well you did against what you planned, celebrate what you've done, and move on to the next sprint.

Also, CI/CD pipelines — continuous integration and continuous deployment. This means you want your code in production, where somebody can use it, as quickly as possible, hopefully multiple times a day depending on your deployment cadence — after all, once a developer's done a thing, it's of no value to anybody until it's deployed. And lastly, quality assurance: you need to make sure testing is in place so you don't break stuff as you go. As part of the CI/CD pipeline you can have automated tests, so that when somebody commits code to a repository it's immediately tested, and if any of those tests fail it doesn't get deployed — it doesn't break anything, it just gives feedback as quickly as possible back to the developer so they can fix it. That way you can keep moving forward with new features while fixing bugs as soon as you find them.

5. Launch preparation

Being Agile, your software should be working all of the time, but you'll want to invite your beta testers as early into the process as you can, well before the MVP is ready for general consumption. Your beta testers can test whether stuff is working the way they like, give you suggestions and feedback, and you should provide a feedback channel for them — either speak to them daily or give them a way to send feedback directly to your developers — so you know what's going right and wrong as quickly as possible. The beta testers can guide you on what's working well and what's working badly.

Also, marketing fundamentals: once your beta tests have got to a certain stage, and you think the software is good enough (not finished, just good enough), you can work on your marketing and spread the word. There should already be a market ready for this software — that's the whole point of doing the market research in the first place. So all you're doing is telling everyone who registered interest that you've now got something to show them — that's your big launch. If you've got enough interest to start with, it should be a great and glorious affair.

The final note on launch preparation is legal consideration. Some of what you're doing may have legal implications, so it's important to check you're not breaking the law in any area, or if it's a grey area, get it clarified by your legal team before you go ahead — things like copyright infringement and so on.

And so there we have it, my list of things to do for startups. Don't forget those metrics to track: how many people are logged in at any time, how many members you've got, how many of those are paying for membership — all good things to see that you're on the right track. If you want more answers to your questions, you can hit me up directly either through tech-answers.club or on my LinkedIn, and I'll be happy to help you out. And, as always, may all your deployments be smooth.