Building Xnappit - An indie project, engineering challenges and tips

In late 2022, I started relearning Swift and SwiftUI, and as a challenge to myself, I decided to test my skills by building Xnappit. It’s a macOS application that allows users to take screenshots and make them look visually appealing without needing to use apps like Adobe Photoshop, etc., to edit before posting to social media.

You and I know time is money; building a product takes time and money. The more people you have in your team, the higher the cost of launching your product, so it’s essential to take the right approach when building a product so it stays within budget. The same applies to indie hackers; I might argue that it is even more important for an indie hacker to take the right approach. “Why,” you ask? Well, as an indie hacker, you have constraints on: - Time - Money - Market

All these things move in unexpected ways, and as a solo builder, you will need to efficiently execute on your product.

In this post, I want to share some of the things I did when building Xnappit, so you can learn how to launch your own indie hacker project and achieve Product Market Fit and eventually get paid.

1. Prototype

I had a rough idea of what I wanted to build, and so I came up with the core functionality that was needed to solve the problem:

• Take screenshots
• Edit screenshots
• Save screenshots

I defined the following constraints when building this initial prototype:

• It should be built in less than a week
• It should not need a fancy UI
• It should not follow best coding practices
• It should WORK!

Doing this allowed me to grasp the technical feasibility of the project and anticipate some challenges that would arise, while also helping me make mistakes that could inform me when building the production implementation of the product. This made sense for me personally since I was relearning SwiftUI and was unfamiliar with NSKit and other macOS APIs.

After 5 days, I finished the prototype and was ready to take my learnings to the next step.

2. Building Xnappit

Planning and ways of working

I performed some high-level planning to define the initial direction and path forward, and because of taking the time to work on prototyping early on, this phase was mostly focused on coding.

The mantra that guided me during this phase was: “build to find product-market fit,” so I focused on the most important aspects of the product and getting early adopters so they can provide constructive feedback during beta.

The point is to think of your indie project as an experiment, and you need to make sure that you get feedback early on to ensure your hypothesis is correct.

Timeline

The first line of code was written on the 22nd of December 2022, and version 1.1 was launched to the general public on the 31st of January.

3. Technology choices and engineering approaches

The technology stack for the product was decided before building it. I had chosen Swift and SwiftUI. An alternative would have been to use Electron, but I was enthusiastic about building something that was native to macOS.

Additionally, I wanted an excuse to build it with SwiftUI. The last time I had touched Swift was in 2015; back then, I was playing around with it in Ubuntu as I did not have a Mac at the time.

4. Engineering Challenges

One of the challenges I faced was actually capturing the screenshots on macOS, as neither the SwiftUI nor AppKit API’s expose this functionality directly.

Another was keeping memory usage low when applying updates to the screenshot being edited in the Canvas, I initially had tons of memory leaks and after edit the memory would increase 1.5x every time an edit was applied. I later to managed to keep the memory usage low by implementing a temporary fix which entailed downscaling the size of the original screenshot in memory then saving it in the expected resolution when the user performed a save.

Testing approaches

There are two schools of thought for testing:

a) Don’t do automated tests until you get to product-market fit.

b) Assume you’ve already found product-market fit and add automated tests

What approach would you have chosen for your indie project? I decided to skip automated tests altogether. Why? The product was a fat client, automated tests would not make sense as in the initial phase the UI would most likely change a lot, so moving fast based on user feedback was of higher priority.

Other tips

Here are some of the things I decided to follow while building the product:

• Don’t do automated tests for UI
• Don’t spend time building what is not necessary to test your business hypothesis
• Performance improvements can be made later as long as they don’t severely impact user experience.

Hopefully, these tips help you when building your own product.