We know that trust is super-important when choosing any software. That’s even more so the case with billing software. If you choose Upmind to help you run your business, you need to know that we are a solid, reliable team and we are here as a permanent solution that will continue to improve Upmind. There are plenty of software solutions that look great but which are later abandoned, or where the focus changes.
We are an open company and have nothing to hide. I want to go through a few things in this blog article that explains our process and how we work. Hopefully by the end of the article you will understand more about the way we do things and why. You can find out more about the history of Upmind in a previous article.
Team structure
At the core of Upmind is a team of 9 full-time developers who have worked together since 2018. We also have some other team members who look after infrastructure, documentation etc. Most of the team have worked together for longer than that. In the four years we have been building Upmind only two developers have left us, both on good terms and both for career progression elsewhere.
Upmind’s development team can be divided into three sections: backend, frontend and provisioning. You will find us refer to these teams and systems in some of our documentation and forums as BE / FE and Provisioning. It is useful to know how they fit together.
Upmind Backend (BE)
Upmind is API-first. This means that at its core Upmind is a frontend-less application that just exposes API endpoints. If we build a feature then the backend will write a number of API endpoints to manage that feature. The brains of Upmind is code and logic, with no interface whatsoever.
Upmind Frontend (FE)
Our frontend is essentially just what we think is a really nice way to use our software. It interacts with the Upmind BE via API calls. Upmind is beautiful and a pleasure to use. But if you wanted you could write entirely your own frontend no differently to how we have.
Provisioning
Tightly coupled to the backend but completely standalone is our provisioning system. This is what allows you to use Upmind to integrate with other services' own APIs to manage them. For example to create hosting accounts, manage software licences, set up and terminate servers, brew you a coffee, renew domains, etc.
So far we have only realised a tiny fraction of the potential of our provisioning system but much more is coming soon. In theory it is infinitely extensible and you could make product events in Upmind do whatever you want with your third party systems.
Separation of duties
Our frontend is ‘dumb’ and has no logic. Our provisioning similarly has little ‘logic’ but is a way of unifying various third party systems with one set of functions the backend can internally call.
All user security is implemented on the backend, rather than the frontend. If you create a staff member with restricted permissions, then that directly restricts the API calls which that staff member can make. All currency conversions, validation and more happens on the backend. An API call for instance that gets a product would return prices in various formatted versions.
In terms of security between the provisioning and the backend, this is essentially totally separate and the two communicate via APIs and two-way encryption. The majority of our provisioning system is open-sourced (or in the process of being open sourced) and could be used for other needs. Eventually users will be able to run their own (or multiple) instances of our provisioning system.
Who runs what
Upmind BE is led by Boris Kolev. Prior to Upmind, Boris built Bulgaria's largest job board, created a custom client billing and management system for Europe's largest satellite internet company, and began planning the foundations of Upmind with me at the world's largest hosting company. Boris is joined in the backend team by Nayden, Ivo and Nicky.
While there is some crossover with the backend team, our provisioning setup is really the sole achievement of Harry Lewis who has been working to plan and create this solution for years. Harry also worked with me at my previous hosting business where we ran, built and customised a large number of disparate internal proprietary and third-party systems.
The frontend and UX side of things is led by Chris Garner – with Dominik, Ibrahim and Matthew making up the team. Chris previously managed the eCommerce platforms for HostEurope, and has years of experience developing web apps and building up numerous online brands from scratch.
I’ve linked to everyone’s LinkedIn profiles where they have them so you can see them directly. And here is mine.
Code quality
We definitely aspire to perfection. That doesn’t mean what we have built is perfect or doesn’t need improvement - it definitely does and we are our own harshest critics. But we are proud of the code we put out.
I think the frontend speaks for itself. Obviously it is javascript and the code can be inspected by someone with technical knowledge, but it’s also a beautiful application and the OCD that went into designing it also went into structuring and building the framework and code. In the future, we have plans to release a ‘Headless’ Upmind – making it easy for others to develop their own UI using progressive frameworks such as Vue and React.
We have also started open sourcing our provisioning system, which is based on the Laravel framework. You can hopefully see there the quality and logic of our code.
We have some refactors to do of our API, to make it OpenAPI v3 spec. Once that is done and we publish full API docs, we hope that API users will be impressed by the logic and neatness of that also.
Metholodogy
We don't subscribe to a particular methodology (e.g. Scrum) but instead have a working pattern we adapted to that works very well for us.
Typically when we work on a new feature or make a change it will be specced at quite a high level of abstraction. We will define what we want it to do - which is often logical. We use git for issue tracking, and an issue will be created in git.
One, or a combination, of the backend team will work on the feature and provide endpoints and create a frontend issue. The backend feature will be merged and deployed to a staging environment.
One of the frontend team will then work on the issue and we create a feedback loop between the backend developer, the frontend developer, and whoever is testing the feature from a usability perspective. Often we end up making tweaks and changes to how we originally intended the feature to work.
Obviously at each stage code is reviewed and then heavily tested before being deployed to master. It is extremely rare that we ever have to roll back a deploy but if we did it would take a few seconds.
We love working like this. It enables us to quickly make amazing features without having to deeply specify functionality, or have a team of project managers. It also enables us to iterate feature advancements. For example, yesterday we released a support pin function to allow a staff member to quickly verify a client; we were able to go from planning to pushing it live within 4 days. But even in that time we made multiple changes and we have thought of really clever ways to extend it and make it even more useful in future that we would not have come up with even a month of pre-planning.
Customer feedback loop
We have developed a very close relationship with some customers (including with some brands that I run myself) which means that in the early alpha stages of Upmind we were able to get feedback very quickly on usability and also find functionality gaps that we needed to fill. It also allowed us to heavily test Upmind at a substantial scale - some of these brands have 40k+ clients.
As beta users came onboard we've developed similar relationships with other customers whose feedback we take on board and then create a loop with.
We still have a large number of features we ourselves think would be amazing that we will be working on. Upmind will never be a 'finished' application and will always be improved.
Roadmap
While we internally roadmap, we are not yet publicly setting ETAs and a roadmap. This will come once we lose our beta designation - likely at the start of 2023.
Where we are based
Before Covid we were office based. Half the team is in London and half the team is in Sofia. We had amazing offices in both locations. Once Covid hit, we adapted really quickly to working from home. We have daily standups and exceptionally strong communication. We use Slack constantly.
Of the UK office, Ibra moved overseas and everyone else moved West out of London to the countryside. some (Matt) even as far as Cornwall. In Bulgaria, Boris' lockdown project was to build his own office extension based on Youtube tutorials, so while we still maintain an office in central Sofia, often the team meet there instead.
We meet face-to-face quite often to discuss plans and have a beer, but our productivity has never been higher.
Planned changes
Upmind is a bootstrapped organisation funded by me. We want to build awesome software for the long-term. We will get to break even relatively soon, and do not plan to take any outside investment.
We will be looking to roughly double our current team over the next couple of years. Even with our big ambitions I don’t see that we would need to grow a large development team to orders of magnitude of what we have.
However, because of the open source nature of our provisioning, we also hope that others will come on board and integrate third-party applications into the Upmind provisioning system and we can build a really awesome developer community.
Once we reach a certain critical mass we'll be looking to have open standups where others can join and we can explain more in depth what we are working on and help directly.
I hope this blog has given you some insight into how we work and the professionalism of our operation. We are always happy to answer any questions and will do so openly and honestly.
