When you’re building software from scratch, it’s natural to focus on building: heads-down concentration on writing code, leveraging APIs, and building the codebase that will become a product. You’re trying to bring your vision to life.
The problem is that two things gradually happen over time.
First, as you continue writing code, it’s easy to have tunnel vision. You only see the next narrow problem that you’re trying to solve. You’re laser focused on getting each little function to work and don’t spend time thinking big picture.
Second, as you bring on another developer and your team starts to grow, building becomes a lot more complex. What worked for a single developer doesn’t translate for three or four developers. Things start to get messy. Things start to slip through the cracks.
Here are 5 areas that you want to be aware of as you build your digital product.
Testing
One of the most common things to skip is tests of any kind. Writing tests, even just unit tests, takes time. It can feel like a chore. It’s not as fun as creating features and slows down shipping code. Should you start with at least some test coverage from the get-go? Probably. Once you’ve gotten into the habit of avoiding tests, it’s hard to start.
Technical Debt
As you’re pumping out lines of code, you’re often just trying to get things to work. But how the code is written matters. Are there deeply nested conditionals? Are functions too long? Are values hardcoded? Are naming conventions consistent? Is the code DRY?
Like all debt, tech debt catches up with you. Poorly written code is a giant headache for future you and other developers. Adding a small feature down the road can take 10 times longer and finding good developers who want to work on messy legacy code can be 10 times harder.
Project Management
As your team grows, communication becomes more complex. There are hundreds of tools and dozens of frameworks meant to address one fundamental problem: how do you get (and keep) everyone on the same page?
It’s harder to do than it seems. Whether you’re running Scrum or using a Kanban board, there are a whole slew of challenges as new people start working together. All of a sudden you need to determine workflow, communication channels, and tracking issues. Your focus shifts from implementation to coordination, from heads-down coding to managing a team.
Developers vs Dev Team
Generally you don’t start with a dev team from day one. You start with a developer. Maybe that’s you. At some point, you recruit another developer. Then maybe a third. Before you know it, you have a small team of developers.
But a dev team isn’t made up only of developers. There are also QAs, UX/UI designers, a DevOps engineer, a Product Manager, and other roles. Early on, a dev team doesn’t have all these roles, but they do have all of the work that each of these roles owns. So a dev needs to write tests, figure out design, and handle infrastructure. The question is: at what point do you add a specialized role outside of a developer? Don’t take for granted that a dev should do it all forever.
Documentation
Whether writing comments in your codebase, adding README files, or creating a full-blown Notion write-up, documentation becomes a big deal for knowledge transfer. And knowledge transfer is just a fancy way of describing when your ideas, vision, and intentions need to go from your head to someone else’s.
Until we start writing something down, we don’t realize how much implicit context we store in our brains. Be prepared to take a lot of time explaining everything in detail.
The MVP Scenario
If you’re building an MVP, you can often get away with ignoring a lot of these things. Your priority is getting some initial user feedback, so you don’t want to overengineer or overspend early on. You may even end up throwing away your code. But if your product is further along, start thinking about things beyond building so that you can build better... and ultimately faster.
