What platforms and frameworks does Marcus output?

Default output: vanilla web standards

Marcus builds with plain HTML, CSS, and JavaScript unless you ask for something else. This means zero framework dependencies, no build steps, and code that runs on any static hosting service. You download a ZIP file with standard files that any browser understands.

This approach keeps the output simple and portable. Your site works immediately when you open the index.html file locally or upload it to Netlify, Vercel, GitHub Pages, or your own server. No installation, no compilation, no package managers.

Adding a backend for SaaS projects

When you describe a project that needs user accounts, a database, or server logic — a booking system, a dashboard, a membership site — Marcus adds a Node.js backend. The stack is Node.js with either SQLite for simpler projects or Postgres for multi-user applications.

This backend runs on the Marcus runtime when you deploy through the platform. You can also export the full codebase as a ZIP and host it yourself on any Node.js-compatible service. The backend code is straightforward: Express for routing, standard SQL queries, session-based authentication where needed.

Requesting a specific framework

You can specify a different stack in your project prompt. Write something like "Build this as a React app" or "Use Vue for the frontend" and Marcus will target that framework instead of vanilla JavaScript. The output structure changes to match — component files, a package.json, framework-specific patterns.

React is the most common alternative request. Marcus generates functional components, uses hooks for state, and structures the project as a standard Create React App layout or Vite setup depending on complexity. Other frameworks work the same way: you name it, Marcus structures the code accordingly.

Keep in mind that framework projects require a build step and dependencies. You'll need Node.js installed locally to run npm install and npm start. This adds complexity compared to vanilla output, so only request a framework if your team already works in that ecosystem or the project genuinely benefits from it.

Where the output runs

Vanilla projects run on any static host. That includes Netlify, Vercel, Cloudflare Pages, GitHub Pages, AWS S3, a shared hosting cPanel, or a folder on your own Nginx server. Upload the files, point DNS, done.

Projects with a Node.js backend need a runtime that supports server-side JavaScript. You can deploy through Marcus (which handles the hosting automatically), or export and host on Heroku, Railway, Render, DigitalOcean, AWS EC2, or any VPS. The database connects via environment variables — SQLite runs as a file, Postgres requires a connection string.

No vendor lock-in

Everything Marcus generates is standard code. There's no proprietary runtime dependency, no Marcus-specific API calls embedded in the output, no licensing restrictions on the generated files. You own the code, you can modify it, and you can move it to any hosting provider that supports the stack you chose.

The export ZIP contains readable, formatted code. Variable names make sense, structure follows common conventions, comments explain non-obvious logic. If you have a developer on your team or hire someone later, they can open the project and understand it without needing Marcus context.

TypeScript and advanced configurations

For teams that work in TypeScript, you can request TypeScript output in your prompt. Marcus will generate .ts files instead of .js, include type definitions, and set up tsconfig.json with sensible defaults. The same principle applies to preprocessors like Sass or build tools like Webpack — describe your requirements and the output matches.

Advanced configurations are possible but require clear instructions. If you need server-side rendering with Next.js, edge functions with a specific provider, or a monorepo structure, spell that out in the initial prompt. The more specific you are about technical requirements upfront, the closer the first output matches your expectations.

When to stick with vanilla

Most marketing sites, landing pages, portfolios, and simple web apps don't need a framework. Vanilla output loads faster, has fewer moving parts, and stays maintainable longer because it doesn't depend on framework update cycles.

Choose vanilla if your priority is speed, simplicity, or long-term stability. Choose a framework if you're already invested in that ecosystem, need features like reactive state management, or plan to scale the project with a team that works in React or Vue daily. Marcus handles both, but defaults to the simpler option because it usually works better.