Tech Stack
Using Tech Adoption Lanes, a personal framework inspired by the ThoughtWorks Tech Radar, modified to reflect the technology stack of a small organization or individual developer.
| Assess | Trial | Adopt | Hold | |
|---|---|---|---|---|
| Languages & Frameworks |
||||
| Tools | ||||
| Platforms | ||||
| Techniques |
Caveat: the technologies here belong to my personal stack, which is not necessarily the same as those used in the teams I build.
The thought process of how the Tech Adoption Lanes framework came about is described in this blog post.
Languages & Frameworks
Assess
- Rust: Experimented on this for a data processing script for an application in production, but I have not used it for anything else.
Trial
- NextJS: Picked this framework at work for its out-of-the-box structure, that would enable us to standardize Frontend development approaches. This has accelerated development needs, but at the cost of deployment complexity due to needing to think about client- and server-side responsibilities (not a clean client-side only approach that allows drawing nice architectural boxes).
- React Native: Currently being used at work to build mobile apps. I had used this in the past for a previous project, but faced significant build issues. After a market study, the ecosystem is much more mature now, the team has experience in it, and for the sake of acceleration a JS-only tech stack suits our needs, so we chose this over Flutter.
- NestJS: Currently being used at work to build services. Chosen for its built-in architectural style, which is straightforward and encourages modularization.
Adopt
- JavaScript: My go-to language for the majority of my personal projects.
- TypeScript: My go-to typesafe language for the majority of my enterprise projects, because typesafety makes data structures explicit. This is crucial for reducing implicitness by making a codebase more transparent, especially critical on team-based projects.
- Python: Mostly for machine learning and data processing.
- ExpressJS: My go-to framework for backend services.
- Vite + ReactJS: My go-to tooling and library for frontend applications.
- NodeJS (others): I do not usually use NodeJS directly, apart for simple scripting. For complex solutions, I would usually go for one of the frameworks like ExpressJS.
- VueJS (others): I use this currently in some personal projects, but I would not consider myself an expert in this framework.
- BPMN (others): I have used this in the past for process automation, and would love to use it again.
- Lua (others): I have used this in the past with the ESP8266 and NodeMCU, and would love to use it again. But it is something I have not touched in a long time.
- Flask (others): Very basic and straightforward framework, the ExpressJS equivalent. I use this for simple Python APIs.
- D3.js (others): I learned this in the past for a Data Visualization project that required development in plain JavaScript. Would use it again in a non-React setting.
Hold
- Ruby + Ruby on Rails: I have fond memories of this stack because I started out my programming journey with the book Learn Ruby the Hard Way and Rails was my very first Web Application Framework. Unforunately, I hit a roadblock with Rails, turned to JavaScript, and have never turned back.
- Dart + Flutter – I love Dart and Flutter, but their use is limited to mobile development, which can be done well in React Native with recent upgrades.
- C/C++: I learned and used this for an IoT project, but redeveloped that project in JavaScript and vanilla NodeJS in a fraction of the time, and never looked back.
- AngularJS: Angular is a great framework as I have heard, but I do not have the expertise in it, and do not see the value in developing such expertise especially with how advanced React is right now.
- Create React App: this was deprecated in 2025.
- Bash: I read a whole book on this once, and understand the syntax. Would use it for small scripts, but I would always default to higher-level languages unless otherwise impossible.
- R: I learned this in the past for Data Analytics, but I defer to Python for Data Science.
- Java & Springboot: I learned Java on my own, and realized it will take many years to become proficient in the Java ecosystem, and those are not years I am willing to invest.
- PEBL: PEBL stands for Psychology Experiment Building Language. I learned this for an academic client, and a very specific framework, and never touched it again.
- Rasa NLU / Core: Used this to build a chatbot, but with GPT models readily accessible, Rasa and its ML + State Machine approach seems relatively obsolete. At the time, the technology also did not live up to its promise.
Tools
Assess
- GraphQL – Would be interested to play with this someday.
Trial
- Cucumber: Used to enable Given-When-Then style of BDD.
- Playwright: Used for React Frontend E2E testing.
- Metro: Used for React Native E2E testing.
- Radix: A component library for React. Selected this after cross-functional discussion with the UI/UX team, for its ready-made React and Figma components.
Adopt
- Nx: A monorepo tool to standardize project structure and enable shared dependencies.
- K8s & Docker: Containerization and orchestration tooling to enable CI/CD.
- Jest: A unit testing framework to enable TDD.
- PostgreSQL: Go-to RDBMS for data storage.
- Markdown: Go-to documentation approach to enable Everything-as-code.
- Mermaid (others): UML diagrams to enable Architecture-as-code.
- PlantUML (others): Other UML diagrams to enable Architecture-as-code.
- NGINX (others): Go-to “API Gateway”.
- Swagger (others): For API documentation and contract generation for sharing between and with other teams.
- MongoDB (others) – Preferred choice for NoSQL database purely for familiarity, but I always default to RDBMSes for databases because of maintainability and clarity of the schema.
- PyTorch (others) – My preferred deep learning framework, for which I have built numerous models with. I have not used this for a while.
- Numpy / Pandas (others) - My preferred data manipulation libraries in Python.
Hold
- TensorFlow (others) – My preferred deep learning framework, for which I have built numerous models with.
- Selenium (others) – A previous E2E tool, but too flaky for scalable E2E testing.
Platforms
Assess
- Raspberry PI: Would love to play with this.
Trial
- Azure Cloud: Currently being used at work to build cloud-based services.
- Novu: Currently being used at work to handle notification workflows.
Adopt
- Vultr Cloud: Go-to cloud hosting platform for small projects.
- Gitlab & Gitlab CI/CD: Go-to Repository hosting and CI/CD platform for all projects.
- Keycloak: Go-to Identity and Access Management platform for all projects.
- JIRA: Project Management tool for Scrum.
- Camunda Platform: BPMN platform for visual process automation.
- Browser Extension (others): Have built Chrome and Firefox extensions, including Quackcheck which is live.
- Telegram Chatbot (others): Used for Quackcheck which is live.
- Airflow (others): For scheduled Data Engineering (Cleaning and Processes).
- ESP8266 (others): Simple, cheap and easily programmable microcontroller.
- NodeMCU (others): An opensource platform for software development of the ESP8266.
Hold
- Trello: I liked to use this on small teams, but recently discovered that Markdown satisfies this role just as well.
- Arduino: Good starter platform, but lack the ability to build complex projects.
Techniques
Assess
- Micro FEs: I have used this, but never implemented from scratch in a project. It’s use in my view is limited to single frontends shared by multiple teams, but most organisations have a single team that owns multiple frontends. From experience, adopting MFEs adds unnecessary complexity and is counterproductive in the latter case.
- Event-driven Architecture: I have used this, but never implemented from scratch in a project.
Trial
N/A.
Adopt
- User Story Mapping: Requirements gathering approach that puts the user first.
- Architecture-as-code: Using tools like Markdown, Mermaid and PlantUML, to keep Architecture as close to the code as possible. This also enables us to drive code changes with architectural decisions.
- TDD/BDD: Using automated testing to drive development ensures high production quality, and reduces the need for a QA function, by ensuring developers own the quality of their own software.
- Scrum & Kanban: Go-to Agile methodologies.
- Developer Experience: A view on development that focuses on the user experience of the development team, to enable developer happiness and productivity. This ensures a longer-term focus on development, and better development morale.
- Developer Productivity @ Scale (others): The focus here is to deprioritize performance to reduce complexity of software systems, and focus on the scalability of feature development.
- Domain-driven Design (others): Focusing on the domain enables simplicity of implementation.
- Unified Modeling Language (others): For software architecture.
Hold
- Waterfall: Software changes fast, the waterfall approach does not adapt easily to changes and shifting requirements.
- Native Mobile Apps: This requires the development of an expertise I do not want to invest in at the moment.
- Performance @ Scale – This one is probably something that confuses most people. Why is performance not seen as important. It is, but not usually at the new product development stage. I place this here as a reminder to myself that performance should always come secondary to developer productivity for the kind of projects I am involved in.