Why receeve?
I was asked this question recently, I had a simple answer. I like hard challenges. That and we also have a diverse team with various backgrounds and expertise that enjoys tackling hard challenges together. If it wasn’t for the latter, I may still pursue the first part, but it wouldn’t nearly be as satisfying.
Prior to founding receeve, I was fortunate enough to have been involved in a variety of types of enterprise challenges over the years - solving problems for the people who are not given the shiny new toys, but who make the machinery of the business work. Of course, it makes it all the more interesting that we can actually apply the learnings that we have had over the years in architecture and scalability in order to do much more that we could have even five years ago. Those who know receeve a little better typically tell us that they don't understand how we have built so much and are able to maintain the speed while scaling across the various countries we operate in. The team we have is so good, that we can bring a large enterprise customer online in hours, not months - a fact we cannot even sell out ‘loud’ with because it sounds hyped to our audience. Deciding on all the settings is a longer process than the technical work.
It is possible with the combination of how we work and how we solve problems. By getting those two things right, we’re able to pick the right tech for the job, explore new things quickly, and deliver results.
Engineering at receeve is being part of smaller, cohesive teams that are able to go end-to-end on a problem. People like cross-functional teams, but we go one step further, where our people can take on cross-functional roles in the delivery of what we build. Everyone can take care of selecting, specking out and implementing the infrastructure that they need for whatever part of the platform they are building or expanding. There is no heavy reliance on a particular person or role in order to make progress on something. The people who fit into our team are those who are driven by curiosity to look for practical solutions.
These close-knit groups are able to decide and execute, learn and iterate quickly. They have decided upon the standards that keep the different services in the platform glued together and it makes life easier. There are guiding principles to help drive alignment between the teams, and you don’t spend a lot of time thinking through the mundane, but actually making things happen.
We are very open when it comes to how developing a part of the platform works. This means that they can run the full spectrum of serverless, containers, instances, or whatever they need to do the job. We mix key/store, relational, NoSQL, and in-memory databases, along with files and ElasticSearch for good measure. When things need to be deployed out to the edge of the network globally, or deep inside a VPC, anyone in the team can.
Our design patterns and abstractions allow us to do things like create new simple services in under an hour. Our codebase is very much Typescript-driven, and it allows anyone that is fullstack to truly move up and down the stack only changing their frame of reference along the way.
With our open communication culture, it’s easy to take an idea, run with it, and see that it works. Take our machine learning as an example. We’ve structured in such a way that any developer can run with creating and executing models in the system, even in Typescript. There was no pressure or being forced to do it some other way just because people thought some other way was right.
Time and time again we have let combining different technologies bring us forward, while still being able to adhere to just the simple principles.
Want to work with us? Check out all the job postings on our careers page.
.png)
