Note: This post was not written/edited/reviewed by any LLM/“AI”.
Introduction
After about a year of working part time on greenfield projects at Outlogic, like small product demos / low scope crypto MVPs, I was tasked with developing a coin swap platform from scratch. At this time I was fully recharged from my days at Widgetic and had moved into a stable cadence of product level thinking while programming, shipping consistently - a direct application of all I’d learned at previous roles.
After the PoC was completed, it was brought to some stake holders who immediately displayed confidence in the UX that I designed/overall features and the project was put on a fast track to production while staying inside the legal bounds of the Swiss financial system.
Chimera exchange in its infancy, was a token swap platform based out of Lugano, Switzerland. At first it carried around 20 mainstream crypto-currencies, notably Bitcoin, Ethereum, Tron etc, and allowed seamless swaps with fast fulfilment.
Ain’t got 99 problems if security ain’t one
Building a crypto exchange is fun, exciting but actually challenging because of the inherent responsibility to be safe with someone else’s money. So without going into the details of the architecture, I can confidently assert that security was the primary and frankly the only concern. Bringing a greenfield exchange to mature revenue is possible only if in infancy one is able to maintain industry level standards of security and compliance. I think this factor of risk is higher with fintech projects, etc because they’re dealing with money right from the get go. As of late, I’ve realised that this is the complete opposite of the vibe coded paradigm of today, where security promptly is relegated the back seat in favour of quick shipping and any security incident comes at the detriment of the early users’ experience.
I should also mention that being based in Switzerland, it was incumbent upon us to comply with strict Swiss data privacy, security and other financial compliance frameworks. So security was never an afterthought, it was the foundation of the whole platform. However, fortunately this engagement did not take up my whole effort budget and I was able to squeeze in some design decisions while building; which is what this blog post will go into in further detail.
The revolving door of developers
As a solo dev, the one thing I enjoy is having complete control over the architecture decisions and the potential of maximum velocity till such a time a team member is added to help you. In my case the management was my boss who was also my product manager. From the first line of code I wrote, I prioritised focusing on shipping milestone by milestone, because as much freedom I had as a solo developer, a lot of constraints on the system were explicit since we had to operate under the purview of one of the most extensive yet rewarding compliance systems in the world. Due to the paradox of choice, this constraint comes to your rescue because you’re not left with the opportunity to overthink / over engineer.
Although I don’t know much about the compliance part of the equation, working alongside a boss who knew the ins and outs of the same after more than a decade of experience alleviated any qualms I might’ve had. So the stage was set, build -> present to stakeholders -> deploy to production, with unprecedented clarity about the KPIs. After writing the basic swapping application that cleared the stakeholder review, the next challenge was to consistently build and deploy while maintaining the highest stanoudard of quality for the end users and operating within the legal framework. It was at this point I decided to take the risk of writing tests, even when I hadn’t crossed 20,000 loc. Writing tests early was a controversial choice because it certainly slowed down the turnaround time for some features but I forged ahead with it anyway. The KPIs were not being met as fast as possible but in hindsight, it was one of the most consequential decisions of the project. Moving fast without regression is a boon with immeasurable benefits overall.
One of the unexpected challenges faced was that apart from myself, there was no dedicated developer assigned to work on the project. Now I consider that a business constraint, so it was never a problem, just a challenge. My insistence on writing tests early in tandem with documentation I created every chance I got(around 30% of the dev time was being spent on creating documentation) helped me tremendously with this unknown. Developers were assigned haphazardly and they would be taken off the project haphazardly too- I must’ve worked with at least 4 developers, and only one of them made any significant contribution to the code.
Conclusion
Building at an early stage is really fun for me, and to be able to shape a platform in its early days is an experience that will stay with me for a long time. However, this stage is also challenging, because bad user experience can break the whole project. In essence, the best outcome could be great growth. There is not much about the challenges faced in this project because I really didn’t do, except for taking the risk of writing tests early and documenting extensively, which I learned at Widgetic. Eventually after a year of rigorous programming and shipping consistently, the users showed faith in us and we booked about EUR 300.000 in orders. As a product engineer, that’s a really satisfying outcome.