# Don't Overengineer, but Make It Work

In my last post, I briefly mentioned “thinking like a user” as a strategy to cut scope and ship a product faster. That’s great when you’re doing product design, but if you’re making engineering decisions, does it still matter?

Everyone knows that users don’t care about what fancy tech you used to build an app. However, that doesn’t mean “pick a stack and charge in blind.” If you want to deliver features that your usual tools can’t handle, it’s better to spend time learning a new tool than it is to work on code you’ll have to throw away.

you could build a house on this foundation, but it's just going to fall over

One of my ongoing side projects is a file manager where files can be connected to each other no matter where they are in the tree. For example, you could have chapters of a book stored as separate files, with one “book” file connecting them together.

The entire point of the project is that it can make arbitrary connections between files– i.e. a graph– so using a graph database will give better performance and make development easier. But when I started the project, I didn’t know how to use graph databases, so I chose to use Elixir and Postgres, assuming I would work faster using a stack that I know. It wouldn’t be an optimal solution, but I thought it would be good enough for MVP, and I could swap out the database once the project was deployed and usable.

In some ways, I was right. Sketching out basic create-update-delete functionality was a cinch, because I didn’t have to learn anything in order to do it. The work went quickly… until I slammed into a brick wall. Graph databases are designed to quickly calculate paths between nodes, but that’s something Postgres simply cannot do. That meant I couldn’t show the user friendly filepaths like /Users/fulgid/my_document.md.

In the end, I had to throw out everything I had written with Postgres and replace it with OrientDB. And because Elixir doesn’t have a good OrientDB driver library, I had to switch languages. Days of work went to waste because I hadn’t considered how my tech stack would affect the features I wanted to deliver.

this is probably what I looked like when I realized I had wasted hours building something that wouldn't work

The thing that went wrong here is the same thing that goes wrong in so many software projects. I had some idea where I was going, but I didn’t take the time to think about how it might affect my decisions. I used well-understood technology in order to work faster, but in the end I only wasted time, energy, and motivation.

Next time you start a project, you should use tools that you know well. But you should also spend a few hours thinking like a user, imagining the features you’re going to build, and considering how that should affect your technical decisions. You might save some time by trying something new.

If “thinking like a user” is appealing to you, you might be interested in my upcoming eBook Building Tech in the Wilderness, which will teach you how to use that user-driven perspective as a map to stay on track, get out of tough spots, and make your project the best it can possibly be. Sign up for my mailing list for more updates!