We Don't Choose
Technologies.
We Choose Tradeoffs.
Every technology in our stack was chosen with a specific reason — and a specific tradeoff we consciously accepted. We will explain both. We will also tell you when we would choose differently, and what we do not use and why.
Every Layer. Every Choice.
Every Reason.
Technology decisions without rationale are just opinions. Every choice below has a documented reason and a documented tradeoff. We will tell you both.
Frontend
Server-side rendering, file-based routing, and API routes in a single framework. React Server Components give us partial hydration — pages load fast even with large data sets because most computation happens at build time or request time on the server.
Next.js adds build complexity and cold start considerations on shared hosting. We have solved this with PM2 process management and careful route configuration — but it requires more infrastructure knowledge than a pure static site.
Animation
GSAP is the only animation library that gives frame-accurate control over complex entrance sequences, scroll-driven animations, and SVG path drawing. Framer Motion is good for component-level transitions — GSAP is for page-level choreography, which is what the CipherBitz site and our client products require.
GSAP's imperative API does not fit naturally in React's declarative model. We manage this with useEffect hooks, proper ref handling, and cleanup on unmount. Requires discipline — can cause memory leaks if handled carelessly.
State & Data
Server state and client state are different problems. TanStack Query handles server state — caching, background refetching, stale-while-revalidate — without requiring a global store. For most product UIs, this eliminates the need for Redux entirely.
TanStack Query adds a learning curve for engineers used to simple fetch calls. It also introduces cache invalidation complexity in optimistic update scenarios. We document cache key conventions per project to prevent stale state bugs.
Backend
Co-locating API routes in the Next.js project eliminates a separate backend deployment for most products. For compute-heavy operations — PDF generation, AI calls, email sending — we keep logic in dedicated API route handlers that can be independently scaled or extracted to microservices when needed.
Next.js API routes run in a serverless-like model that does not maintain persistent connections well. For long-running processes (batch jobs, WebSocket connections), we use a separate Node.js PM2 process — adding deployment complexity.
Database
PostgreSQL is the default for structured relational data with complex queries. Full ACID compliance, excellent JSON support for semi-structured fields, and a query planner that handles complex joins reliably. For products with flat content structures (NammaHubballi listings), MySQL suffices.
PostgreSQL requires more careful schema design upfront than NoSQL alternatives. We invest time in schema review before any migration — this slows initial development by 10–15% but prevents the schema chaos we have seen in MongoDB-based projects.
Infrastructure
Most product requirements are fully served by shared or VPS hosting with a Cloudflare CDN layer. We deliberately avoid cloud-native complexity (Kubernetes, ECS, Lambda) until traffic requires it — over-engineering infrastructure is a common cause of unnecessary monthly burn in early products.
cPanel hosting has less scalability headroom than cloud-native solutions. We plan migration paths to cloud infrastructure at defined traffic thresholds — typically 10k+ daily active users or sustained high compute requirements.
We Have Strong Opinions.
Here Are Four Of Them.
These are not preferences. They are positions we hold after building six live products. We will argue for them and we will also tell you when we are wrong.
Next.js is the right default for most products.
React with file-based routing, API routes, SSR, SSG, ISR, and image optimisation in one framework is the highest leverage starting point for most product builds today. We have tried Vite+React, plain CRA, and Remix — and we return to Next.js for client work every time. The ecosystem, the documentation, and the Vercel-backed maintenance cadence make it the lowest-risk choice for a product that must still be maintained in three years.
When the product is a highly interactive single-page app with no SEO requirement — a dashboard or internal tool — Vite + React without the Next.js overhead is correct.
You don't need Kubernetes until you do.
We have seen early-stage products spend ₹80,000/month on AWS infrastructure for products with 200 daily active users. A ₹4,000/month VPS with Cloudflare in front of it handles most product loads until you have a real scaling problem. Over-engineering infrastructure is vanity — it signals technical sophistication while wasting early revenue on compute you do not need.
When the product requires horizontal autoscaling from day one — real-time features, ML inference, or regulatory data residency requirements — cloud-native is correct from the start.
Database schema designed wrong never recovers cheaply.
The most expensive engineering decisions we make happen before a single line of application code is written — they happen in the schema review. A poorly normalised table structure in a product that grows to 500k records requires painful, risky migrations. We spend more time in schema review than most teams expect — and that investment pays back in every migration we do not need to write.
Rapid prototypes and throwaway MVPs benefit from looser schema discipline. If the goal is to validate an idea in two weeks, schema rigour should be deferred — explicitly, with a documented refactor plan.
Technical SEO is a first-class engineering concern.
Schema markup, Core Web Vitals, crawl budget, canonical strategy, and server-side rendering are engineering problems — not marketing problems. The products in our portfolio that rank well do so because SEO decisions were made at the architecture level, not bolted on after launch. A product built with SEO as an afterthought requires a rewrite to fix properly — you cannot retrofit server-side rendering into a client-side app cheaply.
For B2B SaaS products behind authentication, or internal tools with no public indexing requirement, SEO architecture is irrelevant and should not drive frontend decisions.
The Technologies We
Deliberately Avoid.
What a team does not use is as revealing as what it does. Here is our no-list — with honest reasons.
MongoDB
Schema-less databases accumulate inconsistency silently. We have inherited MongoDB codebases where field names changed across documents, types drifted, and queries became unreliable. For product data with relationships, PostgreSQL's schema constraint is a feature, not a limitation.
Content-heavy CMS projects with highly variable document structures and no relational joins. Blogging platforms. Not product backends.
Redux
TanStack Query handles server state. Zustand handles UI state. Redux adds boilerplate, reducer pattern complexity, and action verbosity that we cannot justify for the state complexity of the products we build. The only redeeming feature of Redux is DevTools — and Zustand has those too.
Extremely complex collaborative real-time applications where predictable state time-travel debugging is genuinely needed. Not typical product builds.
PHP / Laravel (new builds)
We maintain WordPress and NammaHubballi in PHP. But new product builds in PHP in 2026 have no advantage over Next.js except familiarity for PHP developers. We do not start new products in PHP.
WordPress plugin development, WooCommerce customisation, and maintenance of existing PHP codebases. We do this — we just don't start new projects here.
AWS / GCP / Azure (as default)
Cloud provider complexity is not free. IAM policies, S3 bucket configs, VPC setup, and billing surprises add engineering overhead that is not justified until a product has a genuine scaling problem. We start on VPS + Cloudflare and migrate when there is a real reason.
ML inference workloads, regulated data environments requiring specific residency, and products that will scale to millions of requests before the first year of launch.
GraphQL (as default)
REST API routes with typed interfaces cover 95% of product requirements at a fraction of the GraphQL setup cost. GraphQL's benefits — flexible queries, schema introspection, reduced over-fetching — materialise in large APIs serving many clients. Single-product APIs rarely need it.
Products with multiple client types (web + mobile + partner API) that each require different response shapes from the same data layer.
WordPress (new product builds)
NammaHubballi is WordPress — we operate it daily. We understand the platform. But WordPress is a CMS, not a product framework. Plugin dependency chains, PHP version conflicts, and database query performance at scale are problems we do not want to own for new product builds. Next.js gives us control.
Local business directories, blogs, portfolio sites, and content-heavy sites where the WP ecosystem saves 6–8 weeks of build time. We still build and maintain these.
The Same Stack Runs
All Six Products. Today.
Not described on a slide deck. Running in production, serving real users, being maintained and scaled right now.
FreeBill
AskBLR
NextGirl
Five Engineering Principles.
Applied To Every Project.
These are the non-negotiables. Every codebase we write, every schema we design, and every deployment we configure follows these five principles — or we explain in writing why we deviated.
Choose boring technology first.
The most exciting technology is rarely the right technology. We default to well-understood, well-documented, well-maintained tools — and only adopt newer technologies when there is a specific problem that existing tools cannot solve well. This reduces onboarding time, bug surface area, and the risk of a dependency becoming unmaintained two years into a product.
Performance is a first-class feature — not an optimisation.
Core Web Vitals, image optimisation, font loading strategy, and JavaScript bundle size are designed into the product from day one — not measured and fixed after launch. A product that loads in 1.2s converts differently from one that loads in 3.4s. We treat every millisecond of LCP as a product decision.
Schema review before any application code.
Every project begins with a schema design session — tables, relationships, indexes, constraints, and naming conventions documented and reviewed before any ORM models or API routes are written. A schema decision reversed after 50,000 rows of data is a migration. A schema decision made correctly on day one is invisible — as it should be.
Deploy to production on day one.
Every project is deployed to a live URL on day one of development — even if it only shows a placeholder. This prevents the 'it works locally' problem, surfaces infrastructure configuration issues early, and creates a real URL for stakeholder review at every stage. Development that only runs on localhost is not done.
Document why — not what — in code comments.
What the code does is readable from the code. Why a specific decision was made is not. Every non-obvious architectural choice — a denormalised table, a specific cache strategy, a deliberate deviation from a pattern — gets a comment explaining the reason. Future engineers (and our future selves) deserve to understand the decision, not just inherit it.
Three Ways to Build
On This Stack.
Full Product Build
Your product built on our production-tested stack — Next.js, PostgreSQL, Cloudflare, designed and deployed with the same engineering principles and patterns that run our six live products. You get a decade of stack refinement from day one.
Technical Stack Audit
Already have a product but suspect the stack is causing performance issues, maintenance headaches, or scaling concerns? A structured 5-day technical audit with a written report and a prioritised refactor roadmap.
Technical Advisory
For technical teams who need a second opinion — on a stack decision, a schema design, an infrastructure choice, or an architecture direction. Monthly retainer with async review and structured opinion sessions.
What Are You
Building Next?
Tell us what your product is, what stack you are currently on (or starting from), and what is causing the most pain. We will tell you what we would choose, what we would avoid, and why — honestly, without a sales agenda.