The Tech Stack We Use in Our Creations (and Why)

A lot of agencies talk about process, aesthetics, and results. Fewer talk honestly about the actual tools behind the work. But if you are hiring a digital team—or if you run one yourself—the stack matters more than most portfolios admit.

At kreasikita.co, we do not choose tools because they are trendy on X or because they look good in a proposal deck. We choose them because they help us ship faster, keep maintenance reasonable, and build products that fit the client’s real stage of business.

Our current tech stack agency web setup is centered around six tools: Next.js, Supabase, Tailwind CSS, Vercel, Figma, and n8n. This is not a “perfect stack,” because no stack is. It is simply the combination that gives us the best balance of speed, flexibility, developer experience, and cost for many modern web projects.

In this article, we will break down why we use each tool, the trade-offs versus alternatives, and when each one is the right fit for a client.

How We Think About Choosing a Stack

Before getting into specific tools, it helps to understand the criteria we use.

We usually evaluate a stack based on four practical questions:

1. Can it help us move fast without creating future pain?
2. Can it scale with the client’s needs, at least for the next stage of growth?
3. Is it maintainable by a small, efficient team?
4. Does it make sense financially for the project?

That last point is important. Not every client needs an enterprise-grade architecture. Sometimes the smartest decision is a stack that is simple, stable, and easy to hand over. Other times, the project needs more customization, stricter security, or deeper backend logic.

So when we talk about our stack, this is not us saying “everyone should use this.” It is us saying: this is what works well for the kind of websites and digital products we most often build.

The Core Build Stack: Next.js, Supabase, and Tailwind

These three tools make up the heart of many of our builds.

Next.js for Frontend

We use Next.js as our main frontend framework because it gives us a practical middle ground between performance, flexibility, and modern developer workflow.

Why we chose it:

• Great performance potential through server-side rendering, static generation, and hybrid rendering
• Strong React ecosystem and hiring familiarity
• Good routing, data fetching, and deployment experience
• Works well for marketing sites, company profiles, landing pages, and web apps
• Easy to pair with Vercel for a smooth production pipeline

For agency work, this matters because client projects rarely fit into one box. Some pages need SEO and speed. Some need interactive UI. Some need CMS-like behavior. Next.js handles that mix well.

The trade-offs:

• It can feel heavier than simpler setups like plain React with Vite for smaller projects
• The ecosystem changes fairly fast, so best practices evolve often
• Some features can become overkill if the site is mostly static
• Debugging rendering behavior across server and client can be more complex than traditional frontend apps

Compared to alternatives:

• Vs WordPress: Next.js gives us more frontend control and usually a cleaner modern architecture, but WordPress is still easier for content-heavy teams that want a familiar admin experience.
• Vs Astro: Astro can be better for very content-focused, ultra-fast static sites, but Next.js is more flexible when a project needs app-like interactivity.
• Vs Nuxt: Nuxt is also solid, especially for Vue teams. We choose Next.js mainly because React has broader ecosystem momentum and fits our workflow better.

When it is a good fit for clients:

• Businesses that want a fast, SEO-friendly website with room to grow
• Startups building MVPs or dashboards alongside marketing pages
• Brands that care about performance and custom UI
• Projects likely to evolve beyond a simple brochure site

When it may not be the best fit:

• Very small sites where a simpler static setup would do
• Teams that specifically need a no-code or editor-friendly CMS-first workflow
• Projects with backend requirements better served by a more opinionated full backend system

Supabase for Database and Auth

For many projects, we use Supabase for database, authentication, and backend utilities.

Why we chose it:

• Postgres at the core, which is reliable and familiar
• Built-in auth reduces setup time for login flows
• Useful real-time features when needed
• Good dashboard and developer experience
• Faster to launch than building backend infrastructure from scratch

Supabase is especially useful for internal tools, portals, lightweight SaaS products, and websites that need user accounts without a huge backend team.

The trade-offs:

• While flexible, it is still a platform with its own boundaries and conventions
• Complex business logic may eventually outgrow a lightweight backend setup
• Some teams may prefer full control over infrastructure from day one
• Vendor dependency is lower than some BaaS tools because of Postgres foundations, but it still exists

Compared to alternatives:

• Vs Firebase: Firebase is fast to build with and great for real-time use cases, but Supabase feels more natural for teams that prefer SQL and relational data.
• Vs custom Node backend: A custom backend gives maximum control, but takes more time and budget to build and maintain.
• Vs Laravel or Django backend: These are stronger when the project has complex business processes, admin roles, or heavy backend logic. Supabase wins when speed and simplicity matter more.

When it is a good fit for clients:

• MVPs that need user auth and structured data quickly
• Internal dashboards and admin tools
• Membership sites or client portals
• Startups validating a product before investing in a larger backend architecture

When it may not be the best fit:

• Enterprise systems with very specific compliance or infrastructure requirements
• Products with highly complex backend workflows from the start
• Teams that already have strong backend conventions in another stack

Tailwind CSS for Styling

We use Tailwind CSS because it helps us build custom interfaces quickly without fighting a large CSS codebase later.

Why we chose it:

• Speeds up UI development significantly
• Encourages consistency through design tokens and utility patterns
• Makes responsive styling faster in day-to-day work
• Works especially well with component-based frontend development

For agency projects, Tailwind helps reduce the gap between design and implementation. We can move from approved mockups to production UI with fewer styling detours.

The trade-offs:

• Class-heavy markup is not everyone’s favorite
• It has a learning curve for developers used to semantic CSS structures
• Without discipline, components can still become messy
• Some teams prefer CSS Modules, SCSS, or design-system-first approaches for readability

Compared to alternatives:

• Vs Bootstrap: Tailwind gives more design freedom and avoids the “template look,” but Bootstrap can be faster for simple admin interfaces.
• Vs SCSS: SCSS offers more traditional stylesheet organization, but Tailwind is usually faster for custom UI in modern component workflows.
• Vs CSS-in-JS: Tailwind is often simpler operationally and avoids some runtime styling overhead.

When it is a good fit for clients:

• Brands needing custom visual identity, not generic templates
• Teams that want fast iteration on UI
• Projects where design consistency matters across many components

When it may not be the best fit:

• Teams strongly committed to another styling methodology
• Projects with an existing legacy CSS architecture that should not be replaced casually

The Delivery Layer: Vercel and n8n

Building is one thing. Delivering and operating a project is another.

Vercel for Hosting and Deployment

We host many of our frontend projects on Vercel, especially those built with Next.js.

Why we chose it:

• Very smooth deployment workflow
• Preview deployments are excellent for collaboration and QA
• Strong performance defaults for frontend projects
• Minimal DevOps overhead for the kinds of sites we often launch

For agency work, preview links alone are a big operational win. Clients can review changes quickly, and our team can test updates before production.

The trade-offs:

• Costs can increase as projects scale or traffic patterns change
• It is optimized for a certain way of building, which is great when it fits and limiting when it does not
• Teams needing deep infrastructure customization may prefer self-managed hosting or cloud providers directly

Compared to alternatives:

• Vs Netlify: Similar ease of use for many frontend cases; we lean Vercel because of the Next.js integration.
• Vs AWS/GCP/Azure direct: Cloud platforms offer far more control, but also more setup and maintenance complexity.
• Vs traditional shared hosting: Vercel is much better for modern frontend workflows, though shared hosting may still be enough for basic legacy websites.

When it is a good fit for clients:

• Marketing websites and product sites
• Startups needing fast launch cycles
• Teams that value quick iteration and low deployment friction

When it may not be the best fit:

• Systems requiring custom infrastructure architecture
• Projects with unusual runtime or networking requirements
• Cost-sensitive builds at a scale where another hosting model becomes more efficient

n8n for Automation

We use n8n for workflow automation when projects need systems to talk to each other without building everything from scratch.

Why we chose it:

• Flexible automation builder with good self-hosting potential
• Useful for connecting forms, CRMs, notifications, spreadsheets, databases, and APIs
• Faster than writing custom glue code for every operational task
• Gives clients automation power without a full internal engineering effort

Examples include lead routing, content workflows, notifications, CRM syncing, and internal operations automations.

The trade-offs:

• Complex workflows can become hard to manage if not documented well
• It is not a replacement for a properly engineered backend
• Reliability depends on how well the flows are designed and monitored
• Teams can create hidden operational dependencies if automation grows too organically

Compared to alternatives:

• Vs Zapier/Make: n8n can be more flexible and developer-friendly, especially when customization matters. Zapier may still be simpler for non-technical teams.
• Vs custom automation scripts: Custom code offers more control, but n8n is much faster for many practical business workflows.

When it is a good fit for clients:

• Businesses with repetitive manual digital processes
• Teams needing lightweight integrations between tools
• Projects where automation can improve response time or reduce admin work

When it may not be the best fit:

• Mission-critical systems that need fully custom, deeply tested backend orchestration
• Teams without process ownership, where automation may create confusion instead of efficiency

The Design Foundation: Figma

Before code, there is usually alignment. That is where Figma comes in.

Figma for Design and Collaboration

We use Figma because it is still the most practical design collaboration tool for modern web projects.

Why we chose it:

• Easy collaboration between designers, developers, and clients
• Strong component and design system capabilities
• Smooth handoff process from design to implementation
• Fast iteration during exploration and review

For us, Figma is not just where screens are drawn. It is where decisions get clarified before development starts.

The trade-offs:

• Design files can become messy without structure
• Some teams over-design in Figma and delay real product learning
• It is easy to confuse polished mockups with validated product decisions

Compared to alternatives:

• Vs Adobe XD or Sketch: Figma has largely won on collaboration and browser-based workflow.
• Vs designing directly in code: Direct-in-code design can work for some product teams, but Figma is still better for stakeholder communication and early alignment.

When it is a good fit for clients:

• Almost any custom website or product interface project
• Teams that need visibility before development begins
• Brands that care about consistency and structured UI decisions

When it may not be the best fit:

• Extremely small, rapid builds where designing in code is faster than formal mockups

Why This Stack Works for Us

The real reason this stack works is not because each tool is “best in class.” It is because they work well together for the kinds of digital products we build most often.

• Next.js gives us a flexible frontend foundation
• Supabase helps us launch backend features quickly
• Tailwind keeps UI production fast and consistent
• Vercel reduces deployment friction
• Figma improves design communication
• n8n adds practical automation without overengineering

That combination supports a workflow we value: move fast, stay maintainable, and avoid unnecessary complexity.

Of course, we do not force this stack onto every project. If a client needs WordPress, Laravel, a headless CMS, or a more custom backend architecture, we evaluate that honestly. The goal is never to defend a favorite tool. The goal is to choose the right system for the business problem.

Final Thoughts

If you are evaluating a tech stack agency web setup, the best question is not “what is the coolest stack right now?” It is: what stack fits the product, the team, the budget, and the next stage of growth?

That is how we think about our own work at kreasikita.co. We like modern tools, but we like practical decisions more.

If you are planning a website, portal, or digital product and want a team that can help you choose the stack realistically—not just sell you buzzwords—feel free to explore our work at kreasikita.co.