What's next for txtcv

A few months ago I started working on a CV builder for software developers. It has now seen some usage beyond just me, and I've learned a few things over the course. This post covers what I'm planning for txtcv in the near future.

From CLI powered to CLI-first

The first change I'd like to make is for the project to be more CLI-driven.

At the moment there is a CLI, but it's more of a frontend rather than being the application itself. If you sign up on txtcv.com, your CV and your job applications and everything else is saved on the server. This choice made sense in the beginning, but the more I work with it the more it bothers me. I'd like to give the user more control and let them store all the data locally, on their disk. The most straightforward way of doing that is to make the CLI front and center.

This doesn't mean that I'd like to get rid of the backend. Running something on the server lets me build features that aren't possible just with a CLI (e.g. generating cover letters using an LLM). Plus, I'd still like to be able to offer a paid tier, and keeping track of license keys is a lot more ergonomic on the backend. Regardless, I imagine this backend to provide optional features, while the majority of the application runs on the user's command line, in their control.

Open-source core

Having a command-line app means the user also expects to be able to read the source code. I personally feel a bit uneasy about installing binaries on my machine without knowing what they do, so I imagine there are others that feel that way too.

So, I'd like for this CLI to be open-source. Given GitHub's recent stability problems, I decided to go with Tangled for this repository, and the source code will be accessible at https://tangled.org/txtcv.com/cli. Tangled, in case you don't know, is a Git hosting service that utilizes the AT protocol extensively.

The repository doesn't contain much at the time of this writing, because it's still very early days for this change. But expect that to change over the next weeks!

Learning Go

Python has been my main programming language for more than a decade now. Recently, I've been itching to experiment with another programming language. And rebuilding this project, I believe, provides me with the perfect opportunity to learn something new.

Like many other software developers, I've been looking at Go and Rust recently. For this project, I wanted to use a language that makes it easy to write command-line applications and has a good deployment story. While both Go and Rust fit the bill, I ultimately decided to pick Go because it's a lot easier to learn as compared to Rust.

I spent some time trying to learn Rust, but it's a massive language with a very steep learning curve, which is a big barrier to get past before I can do anything useful with it. In comparison, Go was much easier to get started with (I spent a weekend working through the Tour of Go and Go by Example), and I was able to write useful code a lot quicker. So, over the next few weeks I'd like to build out the application more and more, and learn Go in the process.


That's the direction I'd like to take txtcv in: a CLI-first, open-source tool that gives you full control over your data, with optional server-side features for the things that benefit from it. And I get to learn a new language along the way, which is always fun.