description: "Tiny Tech Bureau produces sustainable and creative tech solutions based on open-source components. We've learned that reducing the size of tech solutions, in turn reduces their complexity and harmfulness."
We've learned that reducing the size of tech solutions, in turn reduces their complexity and harmfulness. We're critical that tech is the answer to all problems, and therefore we're a very trustworthy consultancy partner for building such solutions. We can produce end-to-end solutions: From designing and planning your project — to crafting digital tools and products that fit your users and your workflows, using our expertise with a durable open source tech stack.
*We* are me, [Benjamin Balder Bach](https://overtag.dk/), and any freelance friends that I work with in this new setting.
When building a solution with tech, firstly analyze the present situation to understand how it works and what solutions are already in place. We want to learn from this and inform the next solution.
In many ways, like doctors take a hippocratic oath, technology workers can also pledge that they a) will not build a hammer and then look for nails, we will take an approach whereby the needs are understood firstly and b) we will use our knowledge of data, security and access to enforce the rights of users in an ethical way.
The sensitivity of the do no harm principle extends into understanding the meaning that technology has to users. Firstly, we build it based on their needs, secondly we test it with them to get their acceptance. Adding technological layers can easily be a tempting ride whereby unnecessary data and procedures are added. In programming, we apply the principle of YAGNI (you aren't going to need it), same principle is relevant when we build a user experience.
It's much like Occam's Razor, the less we assume about our user's needs, the more likely we are to have identified the correct solution, as in the combination of user experience and technology stack that's most efficient on both a short and long term.
But when we look for simplicity and meaning, we need to be aware that users are different and social interactions can be complex. This doesn't mean necessarily that Occam's Razor isn't true, but we need to account for everything. Or as Einstein said: Everything should be made as simple as possible, but not simpler.
Open Source contains a moral of giving back. It's not that we need to give away useless source code or expose sensitive data, but more that we understand that the tools we are given for free, obliges us to take part in something bigger.
As a publicly owned entity, this has become an overall thinking that includes using the enormous capacity of the public sector to participate in Open Source. In fact, this is already known to be beneficial to build sovereign systems and as an economically superiour model. On all levels of the public sector, it makes sense
As one of the many concepts that have evolved in the push for more Public Code, is the Open Source stewardship. As much as we believe in sharing code, we believe in sharing experiences. The idea of stewarding open source, is not one of being in power or control. It's based on principles of taking responsibility to make sure that a project uses existing experiences and tools to emerge.
Once the strategy is in place, software designers and developers can benefit from guidance at the inception of their project and along the way. We want more than just a LICENSE file in the repository. We want documentation, stakeholders and community around the project that can ensure its sustainability.
Code and technology indeed withers over time when it isn't cared for. Software projects build up technical debt naturally, and the question is when that technical debt becomes an existential threat.
One of the reasons for minimizing a tech stack or being fairly skeptic about technologies is to ensure the longevity of software. A great software platform doesn't look outdated a few years down the road. You know that if you have used software with a very strong and relevant concept.
Sharing contexts means to take part in the world of users and other stakeholders.
There are several reasons why it makes sense for developers and designers to share as much context as possible with other stakeholders, especially users. Firstly, it makes developers able to become designers and make more qualified proposals. But secondly, it also helps to prioritize in harmony.
With rapid development, we mean that the developer should participate in the context/domain that the software seeks to solve problems and create value in. The developer needs direct feedback from seeing the software in use.
This in turn saves costly interactions and translations across actors. By fixing the problem here and now, we don't risk that the context is diluted, nor that elements are lost in transmission or translation between designers and managers. By letting the programmer be the designer, we in turn push responsibility and initiative to the user that gets to instruct the programmer directly. These methods are known also as co-realization and to expand "design space".
The general idea is to always align with what we perceive as the best practices to reach our vision. Using the flexibility of such a stack, you can develop any website or web app at small or large scale.
Having a test strategy is important. And a CI version of testing is crucial to guarantee correctness and allow a fast path to changes. However, we also see testing as something that needs careful crafting - tests need to be meaningful in all aspects of a solution.
If you're familiar with other tech stacks, you'll notice the absence of containerized deployment and big JavaScript frameworks. These add the kind of complexity to a project that will make it expensive to bootstrap and maintain over a longer period of time.
