7 things to have in sight while building your next online business or app

This is what I've learned so far and what I'd do differently with the next one.

1. Study what people do, not only what they say

Market research & product discovery allows you to identify needs, test hypothesis or collect feedback in regards to your initial plans. In a lot of scenarios, this step includes target audience research as well. 

What you may be tempted of doing is to organise interviews and speak directly with potential customers or users. The thing is, usually people are not that open to share their real thoughts with you. 

Some may want to just finish the discussion so they can move forward with their life, others may be afraid of revealing the truth due to the fear of stating something hurtful to you, while a different group might even not understand exactly what you are looking for from them. This can happen even if you have direct access to the right audience.

What could be valuable, in addition, would be to watch what your audience does or does not do naturally.

• if we're talking about a B2B service, you could ask your target group to shadow them an entire day

• if it's a B2C product, try to observe your target audience at different moments of time in their journey

Do not get involved, just watch the activities they engage themselves in and try to observe their needs or pains. 

Could your product make their life better? 

For any of the directions you'd choose, try to put up a rough prototype, as it would explain or validate further your concept in a more reliable manner. Actually being able to get visual or offer your customers the chance of getting their hands on a concept in the research phase, rather than keeping everything at a theoretical level, could give you a key advantage.

Adopt your strategy based on your learnings and carve out a real plan ahead for the next 3-6 months. Anything beyond that is pure fiction, a mere direction of where you'd wish to go.

2. Do not reinvent the wheel, leverage existing tools instead

Let me ask you a question: would you ever write your own authentication system or would you use one that is built, validated & maintained by an entire community instead? The same principle can apply to many more areas of your project. 

That is why you could aim, at least in the beginning, to boilerplate as many parts of a system as you can:

• are you looking to build a SaaS product right away? Consider using packages that bring together in one place the most important elements you'd ever want.

• you're in need of an admin panel? Check out existing pre-built plugins or admin & dashboard templates and start your work with a competitive advantage.

• you wish to get a cool design? Aim to adopt & build on top of an existing design system, rather then sketching every component by yourself.

In any of these cases, the aim is to focus on the value that you can create, not on rewriting parts that have been built before hundreds of times.

3. Bring around you people that can walk the talk

If you're exploring external resources or service providers and you think you've found the right one: hold it right there. Sales rarely equals delivery and you could have a major surprise after closing the deal & starting the work. 

If you've gone yourself through all the steps that come with selecting a vendor, invest time into just one more: vet the team that was proposed to you from that vendor and do not only trust a casting you may not be part of.

Even for your internal team, at least 50% of the members should have had prior experience with the business area, the chosen tech stack or with prototyping ideas prior. I'm all for being a guide for your team and passing know-how further, but you should avoid an extreme situation where you're the only one that is not learning from the others. When mistakes that cannot be foreseen by the team or mitigated in advance will start to pile up, you'll realise that you've got yourself involved in quite an expensive practice.

Last but not least, make sure that the team you've chosen around you actually understands the core mission and the requirements of the product. They way your team starts the work and the first decisions taken will massively influence the future of the project.

4. Be agile. But stay away from Agile

This may be a very, very unpopular opinion. But hear me out.

Can you show me a team that is delivering successfully, on budget, on time & quality according to the business goals with SCRUM? Like... real results, not work that is often made up just to state that something is being delivered, but which will be of no business use for another 3-4 sprints until things get tested, refactored, reengineered, localised, documented and then released?

SCRUM and SAFe are frameworks that may work in mid-large enterprises, where there is no personal stake in a service. Leadership appreciates numbers and knowing that standards are being followed, while team members prefer to stick to their lane or hide between tasks of sub-tasks. It's even not that rare for part of the work to be done a couple of days prior to the sprint end: just enough so that it shows that something was outputted.

Things change though quite a lot as you shift from bigger organisations or agencies that want to sell their time to startups.

Would you ever invest your own money into something that sounds cool, but under-delivers?

Coming from the perspective of an founder or a small business, and not a corporate employee, the answer would be far from positive.

What you could aim for instead is to:

• train your team to focus on the value they can create and not to mask trivial activities as output; it is crucial for them to be able to foresee & tackle challenges upfront, before they become an issue, or to even propose & adopt improvements to the scope you've defined

• deliver product iterations as frequent as possible: seeing things fast in production will enable a stronger sense of responsibility and it will give you also a more direct touchpoint with the market

Being agile means to be proactive, apply holistic thinking, listen to your users, track relevant metrics and frequently change things that do not work in favour of the ones that do.

When your business or app is just ramping up, when you have everything to win and everything to lose, focus on the things that matter. Not on those that give you a false sense of achievement.

5. Think global & never say never

This is a point which is often neglected and ends up requiring more effort than it should've taken with proper planning.

• if you'd ever want to offer support into multiple languages, build your app with localisation principles in mind: it's much, much easier to have available at any given moment a set of files that contain your content in the main language, which you could always translate, rather than having to rewrite your entire system, take the hardcoded text out and swap it with language keys later down the road

• if it's a goal for you to expand to more countries, account for the fact that you'd probably have to support multiple tax rates & local regulations

• when building an e-commerce business, take into consideration that you may end up having 2 or more legal entities and you might wish to swap them out between certain products in your store

You don't have to build all of these functions in full from the start, just to account for them. Architect a system into the right direction so change can be adopted easier when it will be required.

6. Own your tech & plan for scalability

Regardless of who you work with and how you work, make sure that you own & operate the tech that enables your product. Every tool, from the tiniest project management app to the code repository or infrastructure components, you should be in full control of or at least to have it entrusted with someone very close. Chances are, if you lose access to crucial systems, you may reach a state difficult to recover from.

In the same time, aim for a scalable infrastructure, but do not be scared to start small. If you have your code in a repository, if you can access your database & the app is built on strong architectural foundations, there is nothing, but nothing, that will stop you to migrate everything into a newer, more scalable, server setup in a matter of days, should the need arise. And with such a need being clear, potentially your user base would be already higher and this will make bearing the costs of the infrastructure much lighter.

7. Be prepared to pivot

The last one is much easier to talk about and much harder to pull of when you're in the middle of the action, although a good product approach, tech & team will help.

Embrace the uncertainty and be open for changes. The sooner you realise that not everything you've built is what users need, the better it will be for you to make that transition towards the right direction and a more meaningful impact.