Software tooling for Code Pergola
Since we just founded a company, we are just settling in to a collection of everyday software tools enabling our work. Selecting them is a common problem for many companies in their earliest phase.
As a founder, you choose tools that will get you going quickly. But they should also scale well enough that you don't have to worry about them for a while. Unlike a big corporation, you don't want to spend a ton of time on a thorough evaluation process. Experience reports from others certainly helped us on this journey, so we wanted to give back by sharing our own as well.
Our eventual tool choice is based on our specific needs and priorities. These will be different for every organization.
We are a two-people company making software and games. So our essential needs are the following:
- Communication, both live and asynchronous.
- Sharing code, files and secrets.
- Managing our tasks and larger projects.
- Tracking how long we work on what.
All these have to be met for us and for a few select collaborators. Ideally, they will be solved by as few tools as possible.
Navigating the landscape of digital services can be challenging, merely due to the vast number of options out there. It helps to set some priorities.
Obviously, we needed a feature set fitting our intended use case and workflow. This will certainly be a bit different for us as developers who are quite comfortable with fairly technical solutions – but we still care about good UX.
The idea of digital sovereignty comes into play as well. The recent tech sovereignty package by the European Commission highlights the urgency with which this topic is prioritized, especially for European companies like us. The term has been criticized for carrying nationalist undertones and we are wondering if digital autonomy would not be a more fitting description.
In essence, the question is how much you control software – instead of the software (provider) controlling you. So we identified a few key points for orientation:
We want to have control over the software. In that regard, open source helps as by avoiding vendor lock-in as you can usually find an alternative provider, even if you don't self-host the software.
Geopolitically, it increasingly matters where the software is hosted and by whom. GDPR-compliance is the bare minimum. Many common cloud providers are based in the US, where the US Cloud Act allows government access – which is not an ideal situation, to put it mildly. Similar arguments apply to other non-EU jurisdictions.
Furthermore, reliability and ease of maintenance matter. Despite being able to self-host all we need, this is still an argument in favor of SaaS offerings (software as a service) over self-hosting a given piece of software. Letting others host your software comes at some loss of autonomy.
Communication tools
Our initial founding conversations happened via Discord, but we never intended to stay there. As a reliable open source project, Zulip was our first choice and so far this turned out to be a sensible decision. We have successfully invited a few collaborators to join us in chat.
Notably, we use the chat not only for communication, but also for knowledge management. This post by Monadical on making remote work work using Zulip was pivotal to our approach and we have largely adopted it.
By default, Zulip integrates with Jitsi Meet as a call provider. This has been only okay. The amount of random disconnects occurring in our meetings is making us think about looking for an alternative. It is convenient though that chat and calls are modular components that we can swap out independently – something that would not be true for, say, Slack or Microsoft Teams.
Notably, we still use Zulip's US-based cloud offering. It was important to us to have the option to take this and self-host. Preferably, we would find an EU-based provider similar to tab.digital to host this for us. A similar concern applies to Jitsi.
For email, we chose Tuta due to their unique offer to provide easy-to-use end-to-end encrypted emails. There was a small trade-off: since Tuta intentionally does not support IMAP, we are more locked in to their ecosystem of clients and cannot use Thunderbird, for example. Email automation is also not trivial with this approach. So if this ever becomes important to us, we would need to complement Tuta with a more conventional provider.
Sharing files, code and secrets
For sharing files, we are renting a Nextcloud instance from tab.digital. Nextcloud has a large open source ecosystem containing many office and collaboration applications that we occasionally use. However, our primary main use case is syncing shared files across our devices.
We use multiple KeePass vaults (personal and shared) to manage secrets like passphrases. Our favorite desktop client is KeepassXC.
The code for our games and software projects lives on Codefloe. From the beginning it was obvious to us that we wanted to use a Forgejo instance and self-hosting felt like a little too much effort. Codefloe is still quite a young, small provider. So far it has served us well.
We also use Statichost to host our static website, initially we tried the direct integration with Codefloe, but then realized that creating an account on Statichost itself gave us more flexibility.
Project management
Project management is a longer story. We started out trying to unify this with knowledge management by using a synced folder managed by Logseq. Logseq is primarily an outline and note taking software, not unlike Notion or Obsidian.
This approach sounded nice in theory, but was not very approachable and usable in practice. As indicated before, our knowledge management ended up taking place in Zulip chats and Nextcloud folders.
Next, we decided that we wanted a more conventional kanban-style task board and first tried out Vikunja. This worked better, but the breaking point was reached when we realized how much we missed live collaboration, especially during calls when we both manipulated the task board.
Thus, we looked further and eventually settled on Zenkit. This is the only bit of proprietary software in our current tooling stack, but as an EU-hosted solution by a comparatively small provider it still felt like reasonable trade-off given its usability. It has served us well since, even though we are still considering if Nextcloud Deck would not also be able to serve our needs. But so far no migration is planned.
Conclusion
We hope this sheds some light on how we ended up with our current tool stack. Overall, we found it very possible to not buy into the hyperscaler stack using, say, the full suite of Microsoft or Google tools. Our constraint requires a more granular decision process choosing each tool independently and lacks the seamless integration of the dominant office suites. However, from our point of view the data privacy and digital autonomy gains are well worth this extra effort.
If you are a founder and went through a similar process, we would love to hear from you. What were your challenges? How did you overcome them?
Drop us an email and let us know:
We also offer a free 30-min initial consultation. We would be happy to have a look at your current tool stack and make some recommendations. We could even support you setting it all up.