Why GoLazy Exists

Go is a good language for building software that stays understandable. The standard library is useful, package boundaries are explicit, and the compiled program is easy to deploy. But building a full web application in Go can still ask every project to answer the same set of product questions again.

Where do routes live? Where do controllers live? How do views, assets, SEO metadata, JavaScript, background work, and local development services fit together? Many Go libraries solve one piece well. GoLazy exists because I want one application shape that connects those pieces without making the app stop feeling like Go.

Convention as a tool

Convention is not valuable because it removes all choices. It is valuable because it removes the boring choices that every product has to make before the interesting work can start.

In GoLazy, routes, controllers, views, services, assets, and generated browser files all have predictable homes. A small app can start in one file. A larger app can grow into the full structure without changing the basic mental model.

That predictability matters for humans, and it matters even more when coding agents are involved. If the framework gives the app an obvious shape, an agent has less room to invent a different stack every time it touches a feature. The result is easier to inspect, easier to review, and easier to keep boring in the best sense of the word.

One application

GoLazy is biased toward one codebase and one deployable application. The goal is not to pretend that browsers, servers, jobs, databases, and assets are the same thing. The goal is to make their boundaries visible in one place.

That means a controller can coordinate services, render a view, attach SEO metadata, and use generated assets without turning the project into several separate systems. The framework should make that path feel normal.

Plain Go underneath

The opinionated path should not hide the language. GoLazy is built from Go packages, and those packages should stay small enough to understand. When an application needs to step outside the default path, it should still be working with ordinary Go code: handlers, packages, templates, context, and explicit services.

The long-term direction is a smooth path from a one-file app to a full web application. GoLazy should provide momentum, not mystery.