Tech Guidance for Non-Technical Founders

There was a bug in your application's code. An attacker uses it to get the database credentials and extracts the data from every table. The user table contain passwords, emails and names. Other tables contain DOB, addresses, and tax numbers. The impact of this data breach depends a lot on your application's approach to data security. Data security (the confidence that your data is safe from unauthorised viewers and remains uncorrupted) requires a layered approach. This spans from physical...

I often see recommendations to non-technical founders that an MVP is built with a no-code tool. These can be suitable if your particular idea would genuinely benefit from what these offer, but it’s important to realise that these tools are rarely simple, despite being sold as such. They each have their own learning curve and usually require quite a bit of research to accomplish more advanced tasks. When you’re just getting started with your idea, it makes a lot of sense to try to build...

Lately I've been trialling some new developers, which I do periodically. Every time I do, it makes me consider what's really important when assessing whether someone will be a good fit for a project. Obviously experience with the technical stack used on the project is important, as is overall commercial experience. Those and ability to communicate effectively are what I'd generally use to make a decision. More recently I've incorporated attention to detail in the assessment. I define...

Something that can be challenging when describing complex tasks to developers is knowing whether they really understand all the requirements. To some degree, this is just part of normal human interaction and knowledge transfer but there are some ways you can make it less painful. Focus on the outcomeWhen writing up a task, define the conditions and behaviours you will be testing for.In other words, rather than trying to describe the whole solution, you're defining the 'acceptance...

When first working on a new software project, most people I see just want momentum. They want to see the key features developed and feel like they're getting closer to their vision. The thing is as you get closer to selling the software some other things become apparent. One of them is how to segment your application's features into subscription plans. Logically this is easy, but technically it requires adding "gates" around each feature and then checking that a given user is permitted to...

Did you know you can run certain Large Language Models (LLMs) on your own hardware? The two main benefits of this are: The data you share in your AI chat sessions are private You can give the LLM access to your private documents and they won't leave your network It's quite simple to set up: Download Ollama Install it and then choose a model to download. Llama3 is a good choice to start with. Run the model and start chatting with it. The Ollama docs are easy to follow so no need to repeat them...

When building and running software you need to maintain a lot of secrets. As a reminder, secrets in this context means passwords, API keys, multi factor keys, secret keys, etc. I’ve written before about how to manage secrets, but today I want to make the point that you need to pay special attention when securing root credentials. By root credentials I mean credentials which unlock access to other credentials or credential recovery avenues. Examples include: your AWS root account, your...

A lot of agencies sell the ability to easily find a new developer for your project if one leaves. And a lot of agencies actively replace developers on projects frequently, as they optimise their teams across all their projects Despite agencies rationalising this as reasonable in various ways, it's not ideal When any new developer starts on a project they'll need a day to set everything up and do basic familiarisation. Longer if the project setup is not well documented and automated. In...

All business ideas are about solving a problem. The problem could be that a process takes too long. It could be that something is too difficult or hard to define. It could be that something requires a lot of resources that are too expensive to procure for a single person. Sometimes a problem is something the customer doesn't know they have. So businesses are formed to solve problems. But solving the problem isn't enough on its own. What sells a business' products is the customers perceived...

I often tell my clients no: Don’t build that. It’s not important yet. No, we can do it this way and save 90% of the time. I’m trying to show them we only have a certain number of hours before the money runs out or a competitor launches. Sometimes it takes a while to convey my rationale but eventually I see it working. How? Ultimately I want my clients to tell me no. When I give them options I want them to choose the most pragmatic. When they do, I know it’s working. It shows they’re getting...