What Kind of App Did I Build: Static or Full-Stack

Your app is either static or full-stack. Static apps are pre-built files served from a CDN with no server-side code. Full-stack apps have backend logic, databases, and persistent processes running on a server. One sentence tells you which you built: does your app run code on a server?

What's the Real Difference? Static vs Full-Stack Defined

A static app has no backend. All the code runs in the browser, or was pre-built at deploy time. A full-stack app has server-side logic (Node, Python, Ruby, Go) that runs after the user makes a request. The database lives on the server. Static apps are fast and cheap. Full-stack apps handle complex, personalized workflows.

Think of it this way: a static app is a book. The book doesn't change when you read it. A full-stack app is a conversation. The server listens to what you say and responds differently based on your input. The server remembers what you said last time you visited.

Here are the technical markers. A static app has no server process listening for requests. It's HTML, CSS, and JavaScript that ship to the browser. All computation happens locally. The files are built once, stored on a CDN, and served identically to every user. Examples: a landing page, a documentation site, a portfolio, a blog.

A full-stack app has code running on a server that handles requests. When you visit the URL, the server runs code, queries a database, and sends back a response tailored to you. The server is always running. It stores data. It handles authentication. It processes transactions. Examples: a SaaS product, an e-commerce site, a project management tool, a chat app.

The line gets blurry with single-page apps (SPAs). A SPA loads static files but then runs framework code (React, Vue, Angular) that fetches data from a server API. If the SPA only reads data from an API and doesn't store anything, it might look like full-stack but often runs on static infrastructure. If the API is just a database proxy with no custom business logic, the app is mostly static with a data backend. We'll address this in the misclassifications section.

The Decision Tree: How to Classify Your App

Start with three questions: Does your app store user data? Does it run code on a server beyond API calls? Does it need to run calculations or logic that can't happen in the browser? If you answer yes to all three, you have a full-stack app. If you answer no to all three, you have a static app.

Follow this decision tree and you'll know what you built.

Question 1: Does your app store data? Not temporary state on the client. Real data that persists across sessions: user accounts, profiles, posts, files, settings, transactions. If yes, go to Question 2. If no, your app is static.

Question 2: Does your app run custom code on the server? Not just database reads or API proxies. Real logic: authentication flows, payment processing, email sending, business calculations, data transformations. If yes, go to Question 3. If no, your app is a static frontend querying a third-party API (hybrid, mostly static).

Question 3: Is the server running 24/7, or does it only run when needed? Full-stack apps need persistent servers. Even if your server doesn't get traffic 24/7, it must be available when a user arrives. Serverless functions run on-demand. If your entire backend is AWS Lambda or Vercel Functions, you might have a hybrid: static frontend plus serverless API.

The Verdict:

• Yes to all three: Full-stack. You need a database, a persistent server, and hosting that supports both.
• Yes to 1 and 2, No to 3: Hybrid. Your frontend is static (Netlify, Vercel). Your backend is serverless. Cost is lower than full-stack. Deployment is simpler.
• Yes to 1, No to 2 and 3: Static frontend with third-party data. Examples: a JAMstack blog with data from a headless CMS, a React dashboard reading from Firebase. Deploy frontend to a CDN. Store data in third-party services.
• No to all three: Pure static. No server needed. Netlify, GitHub Pages, Cloudflare Pages.

This tree handles 90% of cases. The remaining 10% are edge cases where you're doing something unusual with your backend. If you're unsure, assume full-stack and provision accordingly. You can always simplify later.

Common Misclassifications and Why They Matter

Developers often misclassify SPAs as static or assume their full-stack app is simpler than it is. JAMstack apps are another source of confusion. The cost of misclassification is high: a static budget on a full-stack architecture costs 5-10x more. A full-stack deployment approach on a static app wastes time and money.

Mistake 1: Calling a SPA static. You built a React or Vue app. It talks to an API. You assume it's static because there's no server. Wrong. If the API does any real work, the app is full-stack. You'll try to deploy it to Netlify. Netlify will host your React bundle fine. But your API needs a server. You've now split your deployment across two platforms. Simpler to acknowledge the app is full-stack and pick a PaaS that handles both.

Mistake 2: Calling a full-stack app serverless. You have a Next.js or Remix app with API routes. You deploy to Vercel. It works. You feel like you don't have a server. You do. Vercel runs servers on your behalf. You're paying $20-200/month (or more) depending on traffic. If you assumed serverless meant cheap, you're surprised. Serverless functions are cheap per execution but expensive at scale. A persistent PaaS like Ship or Render is often cheaper if your app has steady traffic.

Mistake 3: Confusing JAMstack with static. You built a Next.js site with some dynamic routes. You use Incremental Static Regeneration (ISR) to rebuild pages every hour. You call it mostly static. It's hybrid. Hosting it on a static CDN won't work. You need a Node.js runtime. You're building a full-stack app, just not one that updates every second. Deploy it like one.

Mistake 4: Assuming a database means full-stack. You use Firebase or Supabase. They manage the database. Your frontend is React. You call the app full-stack because it has a database. Technically, yes. But practically, your backend complexity is low. You might get away with hosting your frontend on Netlify and using Firebase as your backend. This is the hybrid case. Costs are lower than a full PaaS.

Deployment Implications: Why Classification Matters

Your app type determines where you host it and what you pay. Static apps deploy to CDNs: Netlify, Vercel, Cloudflare Pages. Cost is free to $5/month. Full-stack apps deploy to PaaS: Heroku, Ship, Railway, Render. Entry cost is EUR 10-25/month. Misclassification means deploying to the wrong platform and paying 5-10x more than necessary.

Static App Hosting. Upload your files to a CDN. The CDN replicates them globally. Users download from the nearest edge location. Load times are fast. You pay for storage and bandwidth, which are cheap. Netlify gives you 100 GB bandwidth free per month. GitHub Pages is free. Cloudflare Pages is free. A static app costs between $0 and $5/month. Scaling is automatic. You don't manage servers.

Full-Stack App Hosting. You need a platform that runs your backend code, manages your database, and keeps the server running. Heroku was the gold standard. A basic dyno cost $7-25/month. Heroku shut down its free tier in 2022, and prices climbed. Users moved to alternatives. Northflank offers compute starting at $24/month (1 vCPU, 2GB RAM). Railway and Render have similar pricing: $10-25/month entry level. Ship, an Opsily product, offers flat-rate pricing: EUR 800/year (EUR 67/month) or EUR 2,000/year (EUR 167/month) for higher tiers. No per-user fees. Predictable.

Why the price difference? Static hosting is cheap because CDNs buy bandwidth in bulk and use efficient hardware. The server never runs. Full-stack hosting requires always-on compute, database management, backups, monitoring, and support. If you host a full-stack app on static infrastructure (by only using the frontend part), you've moved the problem. The backend has to live somewhere. If it lives on a laptop in your office, you have zero cost but infinite operational burden. You become on-call 24/7.

Cost of misclassification. You built a static portfolio site but hosted it on Heroku ($50+/month). You wasted $600+/year. You built a full-stack app and hosted the frontend on Netlify and the backend on AWS. You split the infrastructure, complicating deployment and adding ~15% to your bill.

The Tradeoff: DIY vs. Managed Infrastructure

DIY (Hetzner + Coolify) costs EUR 3-5/month but requires 4-6 hours of setup and on-call availability. Managed PaaS (Ship, Northflank) costs EUR 10-20/month with zero operations. The hidden cost of DIY is EUR 50-130/month in labor. Choose managed if you have a team or a real product. Choose DIY if you're learning or have strong ops skills.

DIY: Hetzner + Coolify Hetzner is a German hosting provider. A small VPS costs EUR 3-5/month. Coolify is open-source (50,000+ GitHub stars, 3.5+ years development). It automates Docker deployments on your VPS. You connect your GitHub repo. Coolify pulls code, builds a Docker container, runs it on your server. We've compared Coolify to managed platforms in detail: read the DIY vs managed comparison.

The appeal: real cheap. EUR 5/month for production infrastructure. No vendor lock-in. You own the server.

The catch: setup takes 4-6 hours if you've done it before. If you haven't, add 10 hours. You manage security (OS patches, firewall). You monitor uptime. If the server gets hacked, that's on you. If the database fills the disk, you're paged at 2 AM. You become the ops team.

The labor cost: assume your time is worth $50/hour (low for a founder). 4 hours of setup = $200. A month of on-call burden, incidents, and maintenance = 2 hours/month = $100/month. DIY costs EUR 3 + $200 setup + $100 ongoing = $100/month all-in. At that rate, managed PaaS is cheaper.

Managed PaaS: Ship, Northflank, Railway You push code to GitHub. The platform deploys it. Monitoring, backups, scaling, security patches: all handled. Ship offers flat-rate pricing (EUR 800-2,000/year). Northflank's popular plan costs $24/month (1 vCPU, 2GB RAM). No surprises. No on-call. You trust your provider to run your app.

The appeal: hands-off. You don't need to be an ops expert. Faster deployments. Git push to production.

The catch: you're paying for convenience. You're bound to the platform's API. If they change pricing or shut down, you migrate (painful). You lose some control over the infrastructure.

The Math DIY wins on paper if you have deep ops skills and no incidents. Managed PaaS wins if you value your time or want to avoid incidents. For most teams with 10-100 people and a real product, managed is the right choice.

What's Next: Choosing Your Platform by App Type

If you classified your app as static, use Netlify, Cloudflare Pages, or GitHub Pages. Free to $5/month. If it's full-stack, use Ship, Northflank, Railway, or Render. Entry cost EUR 10-25/month. If it's hybrid, deploy your frontend to a CDN and your backend to a PaaS. Simple and cost-effective.

For Static Apps: Use Netlify, GitHub Pages, or Cloudflare Pages. All are free. Netlify has the best UI and best GitHub integration. Deploy happens on every git push. CDN is global. You get HTTPS, custom domains, and build logs. If your static app grows and needs an API backend later, keep the frontend on Netlify and add a PaaS for your backend.

For Full-Stack Apps: Use Ship (if you want flat-rate pricing and zero surprises), Northflank (if you want flexibility and per-resource pricing), Railway (low entry cost, good DX), or Render (similar to Railway). All support Docker, multiple languages, and databases. Pick based on: (1) pricing model you trust, (2) deployment experience (git push is standard), (3) database support you need. We've written step-by-step guides for deploying your GitHub repository to Ship.

For Hybrid Apps (Static Frontend + Serverless Backend): Deploy your frontend to Netlify or Vercel. Deploy your backend to a serverless platform: AWS Lambda, Vercel Functions, Render. Trade-off: serverless is cheap at low volume but expensive at scale. If your backend runs steady traffic, a full-stack PaaS is cheaper. If your backend wakes up a few times a day, serverless saves money.

Next Steps: Once you know your app type, follow the deployment guide for your platform. If cost is your main constraint, read the comprehensive comparison of hosting costs: DIY, Northflank, Ship, and Render side-by-side. We've also compared Heroku alternatives for teams migrating from the old platform.

Frequently Asked Questions

What is the difference between static and full-stack applications? A static app is pre-built HTML, CSS, and JavaScript served from a CDN. All code runs in the browser. No server-side logic. A full-stack app has backend code (Node, Python, etc.) running on a server that handles requests, queries databases, and sends custom responses. Static is faster and cheaper. Full-stack is more flexible.

How do I know if my app is full-stack or static? Ask three questions: Does your app store persistent user data? Does it run code on a server (not just API calls to third parties)? Does the server run 24/7 or always-on? If yes to all three, it's full-stack. If no to all three, it's static. If you answered yes to some but not others, it's hybrid.

What are the deployment requirements for static vs full-stack apps? Static apps deploy to CDNs: Netlify, GitHub Pages, Cloudflare Pages. No servers needed. Cost is free to $5/month. Full-stack apps deploy to PaaS: Ship, Northflank, Railway, Render. Servers must run 24/7. Database required. Cost is EUR 10-25/month minimum. Setup is more complex.

Do I need a database for a full-stack app? Almost always, yes. If your app stores anything (user profiles, posts, settings), you need a database. Some full-stack apps use third-party backends (Firebase, Supabase) instead of managing their own. But the database is still there, even if you don't see it.

Can I deploy a full-stack app to a static hosting service? Only the frontend. The backend has to run somewhere else. If you try to run a Node.js server on GitHub Pages, it won't work. You'd deploy the React frontend to GitHub Pages and the Node backend to a PaaS. This adds complexity. Better to pick one platform that handles both.

Is a single-page app (SPA) static or full-stack? It depends on the backend. A React app that only reads data from an API is a static frontend with a full-stack backend. The React part is static. The API is not. You'll deploy the React to a CDN and the API to a server. If the API is just a database proxy (like Firebase), it's lighter-weight. Either way, the backend needs hosting.

Why does my full-stack app cost more to host than my static site? Because full-stack hosting requires always-on servers, database management, backups, monitoring, and support. CDN infrastructure for static apps is cheap at scale. Server infrastructure for full-stack apps has higher per-customer costs. You're also paying for the convenience of not managing servers yourself.

Is Heroku still the best platform for full-stack apps? No. Heroku shut down its free tier and raised prices. $50+/month for basic apps. Newer platforms (Northflank, Ship, Railway, Render) start at EUR 10-25/month with better DX. Ship offers flat-rate pricing (no surprises). We've reviewed Heroku alternatives in detail for teams making the switch.

The Bottom Line

You have a working app. Now you need to know what you built so you can deploy it right. Static apps are files on a CDN. Full-stack apps are code on a server. The decision tree is simple: does your app store data, run server code, and need 24/7 uptime? If yes, it's full-stack.

Misclassifying your app costs money. A static app on a PaaS is 5-10x more expensive than CDN hosting. A full-stack app on DIY infrastructure is time-expensive. You become on-call. Pick the hosting model that matches your app type and your team's tolerance for operations.

If you classified your app as full-stack and want zero DevOps, managed PaaS is your answer. We've compared costs for full-stack hosting here: the cheapest way to host a full-stack app.