Coder Legion - Recent posts tagged stack

An Engineer's Productivity Stack in 2026: The Tools I Use Every Day

Sat, 01 Aug 2026 19:09:44 +0000

After more than 60 articles, 9 technical series, 4 production applications, and a bilingual blog that generates weekly content, I get asked the same question over and over: "What tools do you use?" Not what tools I recommend, not what tools are trending, but which ones I actually use, every single day, to build what you see on Datalaria.

This article is the answer. No sponsorships, no affiliate links, no filters. Every tool listed here has been tested in production, paid for (or not) with my own money, and documented in at least one post on this blog. If I haven't used it in a real project, it's not on this list.

The Workflow: 10 Phases, 10 Tools

The key to my productivity isn't in individual tools but in how they fit together. Each workflow phase feeds the next, and the output of one tool is the input of another. No silos; it's a pipeline.

Phase	Tool	Why this one
🧠 Think	Gemini Deep Research	Exhaustive research in minutes
✍️ Write	Hugo + VS Code + Markdown	Full control, Git-native, speed
💻 Code	Python + Pandas + FastAPI	The data engineering trident
🗄️ Store	Supabase (PostgreSQL)	Free BaaS, RLS, automatic REST APIs
🤖 Orchestrate AI	CrewAI + Gemini 2.5	Autonomous agents with Tool Calling
⚙️ Automate	GitHub Actions	Free CI/CD, event-driven
🚀 Deploy	Netlify	Deploy from Git in seconds
📧 Communicate	Brevo (Newsletter)	Free email marketing, API, segmentation
📊 Visualize	Chart.js + Vanilla JS	Lightweight, no heavy frameworks, interactive
📚 Learn	NotebookLM	Transforms any source into study resources

🧠 Think: Gemini Deep Research

Before writing a single line, I research. And this is where generative AI has radically changed my workflow. Gemini Deep Research (within Gemini Advanced) is the tool I use for exhaustive research before every article and every technical project.

When I was preparing the article on Thomas Bayes, I needed to verify dates, publications, historical context of the Royal Society, and the precise mathematical connection between Bayes' theorem and Facebook Prophet. What previously would have required hours of browsing through Wikipedia, Stanford Encyclopedia of Philosophy, and academic papers, Gemini Deep Research compiled into a structured report in under 10 minutes, with verifiable citations and sources.

The key: I don't use it to write; I use it to research. The final text is always mine. Gemini gives me the raw material; I build the narrative. I documented this approach in detail in AI in Education with Deep Research.

✍️ Write: Hugo + VS Code + Markdown

Everything you see on Datalaria is written in pure Markdown, edited in VS Code, compiled with Hugo, and versioned in Git. Zero WordPress, zero visual CMS, zero drag-and-drop.

Why this seemingly masochistic decision? Because a Hugo blog is code. I can run git diff to see what I changed in an article. I can run git blame to know when I changed it. I can fork, create a branch, experiment with a new structure, and merge only if it works. And I can automate deployment with a git push. I documented all these architectural decisions in Building Datalaria.

Hugo compiles the 700+ pages of this blog (Spanish + English) in under 4 minutes. A traditional CMS would take several seconds just to render a single page. When you iterate fast, compilation speed isn't a luxury; it's a necessity.

💻 Code: Python + Pandas + FastAPI

The trident I use for absolutely everything involving data:

Python as the base language. No debate. The library ecosystem for data engineering, ML, and automation has no rival.
Pandas for data manipulation, cleaning, and transformation. Every pipeline in the S&OP series — from sales data ingestion to forecast generation with Prophet — goes through Pandas.
FastAPI when I need to expose a service as a REST API. We used it in Part 6 of the Observability series to build the obsolescence radar backend, and in the OpenWeather app as a weather prediction backend.

🗄️ Store: Supabase (PostgreSQL)

Supabase is managed PostgreSQL with superpowers: authentication, Row Level Security (RLS), automatic REST APIs generated from the database schema, and a free tier that covers 95% of my development and prototyping needs.

I use it as the data backend in the Observability series (storing the component catalog, obsolescence alerts, and BOM graphs), in the S&OP pipelines (demand data, forecasts, production plans), and in the Snake game with a global leaderboard.

Why Supabase over Firebase? Because Supabase is real PostgreSQL. I can write native SQL, create materialized views, use complex JOINs, and migrate to any other managed PostgreSQL (RDS, Cloud SQL) without changing a single line of code. Firebase traps you in its proprietary ecosystem; Supabase includes the exit door.

🤖 Orchestrate AI: CrewAI + Gemini 2.5

When I need AI to not just answer questions but execute complex multi-step tasks, I use CrewAI as the agent orchestration framework. Each agent has a role, an objective, specific Python tools (decorated with @tool), and the ability to coordinate with other agents.

Gemini 2.5 Pro/Flash is the LLM powering the agents. The CrewAI + Gemini + Tool Calling combination is the architecture documented across the entire 9-part Autopilot series, from the automatic content generator to the Ops Copilot.

As we analyzed in the RAG vs. Tool Calling article, the key is separating the "semantic brain" (the LLM understands context) from the "deterministic muscle" (Python tools execute precision operations). The LLM thinks; the tools do.

⚙️ Automate: GitHub Actions

Every CI/CD pipeline at Datalaria runs on GitHub Actions. It's free for public repositories, event-driven (triggers on push, cron, webhook), and flexible enough to orchestrate everything from Hugo compilation to CrewAI pipeline execution.

In Autopilot Part 5, we documented how to configure a GitHub Actions workflow that runs the complete agentic pipeline every week: generates content with CrewAI, creates Markdown files, commits, pushes, and automatically deploys to Netlify. All without human intervention.

🚀 Deploy: Netlify

Netlify deploys Datalaria directly from the GitHub repository. Every git push to the main branch triggers a Hugo build and publishes the site in seconds. Features like Netlify Functions (serverless), redirects, and custom headers cover everything I need without managing servers.

We documented it in OpenWeather app Part 2 as the deployment platform for frontend applications with serverless backends.

Datalaria's newsletter uses Brevo (formerly Sendinblue). Generous free tier (300 emails/day), REST API for automation, audience segmentation, and a template editor.

In Autopilot Part 6, we documented how the CrewAI pipeline generates email content, builds the HTML, and sends it automatically via Brevo's API — closing the complete generation → publication → distribution cycle without manual intervention.

📊 Visualize: Chart.js + Vanilla JS

When I need interactive charts in web apps, I use Chart.js with vanilla JavaScript. No React, no Vue, no heavy frameworks. The philosophy is intentional: every library you add is a dependency to maintain, an attack surface to protect, and a bundle to inflate.

OpenWeather app Part 4 and Basic Visualizations demonstrate that Chart.js + pure CSS produces professional-quality interactive dashboards without needing a 200KB framework.

📚 Learn: NotebookLM

Google's NotebookLM is my accelerated learning tool. I upload technical documentation, academic papers, or conference transcripts, and NotebookLM generates summaries, study questions, and — most transformatively — audio podcasts where two hosts discuss the material as if it were a natural conversation.

I documented it in depth in NotebookLM + SQL, showing how to transform PostgreSQL documentation into interactive study resources.

What I Tried and Discarded

Not everything you try survives contact with production. These are the tools I evaluated and discarded, with reasons:

WordPress: Used it for years. Abandoned it for the slowness, the plugins, the constant security updates, and the impossibility of versioning content with Git. Hugo is 100x faster and everything is code.
LangChain: LLM orchestration framework I tried before CrewAI. Too much abstraction, deep inheritance chains that were hard to debug, and an API that changed with every minor version. CrewAI is simpler, more explicit, and more stable.
Streamlit: Excellent for rapid data dashboard prototypes. But when you need control over the frontend (CSS, animations, UX), Streamlit becomes a straitjacket. For production, I prefer FastAPI + HTML/CSS/JS, where I have full control.
MongoDB: Tried it as a PostgreSQL alternative for semi-structured data. But the lack of JOINs and the impossibility of complex relational queries quickly ruled it out for my industrial use cases (BOM graphs, demand table cross-referencing).

Total Stack Cost: The Real Economics

This is where the Hidden Economics of AI becomes directly relevant. How much does operating this entire stack cost?

Tool	Monthly cost	Notes
Gemini Advanced	~€22/month	Includes Deep Research, 2.5 Pro, etc.
Hugo	€0	Open source
VS Code	€0	Open source
Python + libraries	€0	Open source
Supabase	€0	Free tier
CrewAI	€0	Open source
GitHub Actions	€0	Free for public repos
Netlify	€0	Free tier
Brevo	€0	Free tier (300 emails/day)
Chart.js	€0	Open source
NotebookLM	€0	Included in Gemini Advanced
TOTAL	~€22/month

Virtually the entire stack is free or open source. The only recurring cost is the Gemini Advanced subscription, which covers both Deep Research and the models powering CrewAI agents. Even if we count Gemini API costs for Autopilot pipeline executions, the total rarely exceeds €5 extra per month.

Compare this with the cost of an "enterprise" stack: a licensed CMS (€50-500/month), a premium email marketing tool (€30-200/month), a managed hosting service (€20-100/month), and a BI platform (€50-300/month). The open source stack isn't just cheaper; it's more powerful, because every tool is a box you can open, inspect, modify, and learn from.

The Philosophy: Learning > Comfort

If there's a common thread across every decision in this stack, it's this: I prioritize learning over comfort. Hugo is harder than WordPress, but I learned static site generation, Go templates, and CI/CD. FastAPI is more work than Streamlit, but I learned REST API design, async/await, and OpenAPI. Supabase with native SQL is more verbose than Firebase, but I learned real PostgreSQL, RLS, and migrations.

Every tool in the stack isn't just a tool; it's a course. And the 60+ articles on this blog are the notes from those courses, shared openly so anyone can walk the same path.

As Deming would say: "Learning is not compulsory. Neither is survival." In a world where AI redefines the rules of the game every quarter, the stack you use matters less than your ability to learn the next stack. And that ability is built by choosing tools that force you to understand what's under the hood.

Sources of Interest:

Choosing the Right Technology Stack for Modern Web Applications

Tue, 28 Jul 2026 09:12:33 +0000

Quick Overview

The stack you choose affects development speed, hiring costs,
scalability, and long-term maintenance, not just launch-day looks.
Frontend and backend choices should map to real requirements:
expected traffic, data complexity, and real-time needs.
Database choice depends on how structured the data is and how often
it changes, not on popularity.
Infrastructure decisions determine how much scaling costs and how
fast incidents get resolved.
Hiring market depth matters as much as technical merit; a stack no
one can maintain becomes a liability.
The most expensive stack mistakes tend to surface 12–24 months after
launch, not during development.

A team picks React and Node because a tutorial made it look effortless, ships an MVP in six weeks, and then spends the next eighteen months fighting the same stack as traffic and feature complexity outgrow what the original setup was built to handle. This isn't a story about bad developers; it's what happens when a stack gets chosen for how fast it demos, not for what the application will actually need to do a year in.

Every layer of a web application the framework rendering the interface, the language running server logic, the database storing records, the infrastructure serving requests is a decision with a lifespan. Get it wrong, and the fix isn't a patch; it's a rewrite. This article covers how to evaluate stack options against real requirements instead of trends, and where teams most often get the decision wrong.

The rationale for choosing a stack beyond the original plan.

Most stack decisions get made during the phase of a project when speed matters most: the MVP, the pitch deck demo, the client proof of concept. That urgency pushes teams toward whatever framework the lead developer already knows, and the same choice keeps making decisions for the team long after the deadline passes.

A framework picked for rapid prototyping often carries assumptions that don't hold at scale: synchronous request handling that chokes under concurrent load, an ORM that generates inefficient queries once tables cross a few million rows, or a rendering approach that was never built for the performance a public-facing product eventually needs. Migrating off a stack after eighteen months of feature development is rarely a weekend's work; it's usually a multi-month project competing with new feature development.

None of this means teams should over-engineer for hypothetical future scale. It means the initial choice needs to account for what's actually knowable about the application's trajectory expected data volume, integrations, and real-time needs rather than optimizing purely for how fast version one ships.

Frontend, Backend, and the Layers of a Web Stack

A technology stack is really four decisions bundled into one: the frontend rendering what users see, the backend handling business logic, the database managing persistent data, and the infrastructure serving all of it reliably. Teams that treat these as a single choice"we're a MERN shop" often miss chances to boost efficiency in web development by matching each layer to what it's actually good at. This is where the case for full stack development services becomes practical: a team that can reason across every layer at once catches integration mismatches, an API shape that doesn't fit the frontend's data-fetching pattern, a schema that fights the ORM before they turn into rework.
Each layer comes with its own trade-offs:

Frontend: server-side rendering for content that needs to be
crawlable and fast on first load, client-side rendering for
interactivity-heavy interfaces, or a hybrid like static generation
with selective hydration.
Backend: enforces business logic and data validation, either as a
monolith that's simple to reason about or as services split by domain
for teams that need independent deployment.
Database: relational databases enforce structure and relationships
well but require migrations for changes; document databases offer
flexible schemas but push consistency enforcement into application
code.
Infrastructure: the hosting and serving layer underneath everything
else scaling costs and incident response times get decided.

The database choice in particular should follow from how structured the data actually is, not from what the team used last time.

Matching stack choices to needs, not trends

The starting point for any stack decision is a short list of concrete requirements — matching each choice to what the application actually needs, rather than what's trending, is one of the simplest ways to boost web development efficiency:

Expected concurrent users at launch and at twelve months
Whether the application needs real-time updates, like live chat
How many third-party services it integrates with

Each pushes toward a different trade-off:

Heavy real-time needs (live dashboards, chat, multiplayer features):
a backend built around persistent connections and event-driven
architecture, where non-blocking I/O earns its added complexity.
Mostly CRUD operations against a well-defined data model: a
conventional request-response backend with a mature ORM ships faster
and stays easier to maintain.

Database and Infrastructure Decisions That Determine Scalability

Scalability problems rarely originate in the frontend framework; they originate in the database and infrastructure layer. A database without a proper indexing strategy, or a schema not designed around real query patterns, will slow down as data grows regardless of how optimized the application code is. Read replicas, caching, and connection pooling all work around database bottlenecks, but each adds operational complexity to maintain.

Infrastructure carries a similar trade-off:

Serverless: removes server management, but introduces cold-start
latency and can get expensive at sustained high traffic.
Container orchestration: offers more control over scaling behavior,
but requires dedicated DevOps expertise to run safely.

The right choice depends on whether the team has or can hire the operational skills it requires.

Team Expertise and Long-Term Maintainability

The most technically elegant stack is a liability if the team can't hire for it or maintain it after the original developers move on:

Niche framework: small hiring pool, slower time-to-hire, longer
onboarding since fewer people already know the patterns.
Well-documented stack: deeper talent pool, better tooling,
more community-tested solutions to common problems.

For most business applications, that trade-off favors the mainstream choice.

Common Mistakes Teams Make When Selecting a Stack

Choosing based on what's trending rather than what the application
actually needs
Skipping load and scale requirements during the decision phase
Assuming a popular framework guarantees performance without
evaluating the database and infrastructure separately
Underestimating migration cost once locked into a stack that no
longer fits
Ignoring the hiring market for a given technology until it's time to
scale the team

Conclusion

Choosing a technology stack isn't a single technical decision; it's a compounding one that shapes development speed, hiring costs, and how expensive change becomes over the application's life. Frameworks that demo well in a sprint aren't automatically the ones that hold up at scale. Teams that evaluate each layer against actual requirements- traffic, data complexity, team skill, and maintenance cost- end up with a foundation that supports growth instead of one that has to be rebuilt around it.

Frequently Asked Questions

1. What is a technology stack?

A technology stack combines languages, frameworks, databases, and infrastructure tools used to build and run an application across frontend, backend, database, and hosting layers.

2. How do I choose the right stack for my project?

Start with concrete requirements: traffic, data complexity, real-time needs and consider team expertise alongside technical fit.

3. What's the difference between a stack and a framework?

A framework is a single tool in one layer, like a frontend library. The full stack combines frameworks, languages, databases, and infrastructure.

4. Does your stack affect SEO and page speed?

Yes. Frontend rendering impacts content visibility and crawlability, while backend and database performance affect response times; both influence search rankings and Core Web Vitals.

5. Should startups use the same stack as large companies?

Large companies optimize for scale problems startups don't face yet, whereas startups benefit from stacks that maximize development speed and hiring flexibility early on.