A new Android project,
already wired up.
Multi-module Compose with MVI, Hilt and Ktor. Four build environments, signed release output, a design system with no Material dependency in one of four styles, and a catalog app that shows every component. Pick what you want, get a zip that compiles.
No sign-up, nothing stored, no email. The zip is built when you click and streamed straight back.
This is beta. Every feature on, every feature off and both big presets are compiled, tested and linted in CI before a change ships, but not many people have used it yet. If something breaks, the button in the corner sends a report straight to whoever can fix it — and it attaches what you configured, so you do not have to describe it.
$ ./gradlew :app:assembleDevDebugBUILD SUCCESSFUL$ ./gradlew buildcompiles 7 variants · unit tests · android lintBUILD SUCCESSFUL in 6m 3s$ ./gradlew :app:distDevReleaseMyApp-devRelease-arm64-v8a-1.0.0-1-20260904-1048.apkMyApp-devRelease-universal-1.0.0-1-20260904-1048.apkchecksums.sha256
Each removes a module, not just code
An androidx.compose.material import fails the build
Utility, Social, Editorial, Playful — one enum
dev / staging / prod / playstore × debug / release
Builds on Android Studio's bundled JBR
Design styles
Four looks. One codebase.
The same components and screens, with one enum changed: AppTheme(designStyle = …). Pick one here, then make it yours — every component is plain Compose you own.
Drawn in your browser from the template's own tokens and copy, with the brand colour and typeface shown under each. The catalog app switches between all four live on a device.
This part is not optional
Everything below arrives whatever you tick. It is the reason the template exists, and the part that would take a fortnight to assemble by hand.
A design system with no Material
verifyComposeUsageBuilt on androidx.compose.foundation and ui alone. Its own ripple, type scale, 80-odd components, date and time pickers, bottom sheet, charts and a hand-drawn icon set. An androidx.compose.material import fails the build, so it cannot drift back in.
One place for the look
AppThemeColour, type, spacing, shape, elevation, motion and haptics are composition locals read through AppTheme. Changing the font is one string, a brand colour is one hex and the ramp around it follows, and how every control answers a finger is one enum.
Navigation nobody has to coordinate on
Navigation 3A feature registers its own screens through Hilt multibinding. Adding one touches no file outside its module — there is no central sealed Route to extend and no when in :app to add a branch to, so two people adding screens in the same week do not conflict.
Designed for every screen, not just phones
AppTheme.windowSizeLayout follows Android's window size classes, never orientation or device. The tab bar becomes a rail from tablet width, a list and its detail share a wide window, and forms and text stop at a readable width. Locking an activity to one orientation fails the build.
Tabs that feel like tabs
AppShellEach tab keeps its own back stack, scroll position and ViewModels, and switching crossfades rather than sliding like a push. The bar slides away over content that never changes size. Re-tapping the active tab pops it to its root, and Back at a tab root goes to the first tab.
A look you pick, then own
AppDesignStyleFour design styles change corners, borders, fields, the tab bar, surface tone and type weight together, each checked against WCAG AA in both themes, and four motion styles change how everything moves. Both are one argument to AppTheme. The components are plain Compose in your own module, there to be reshaped.
Instructions for your AI agent
AGENTS.mdAGENTS.md, with CLAUDE.md pointing at it, tells an agent how the project is laid out, what the build refuses, how a feature is shaped, and to comment like the person who owns the code rather than narrating every line.
Seven build variants
AppFlavordev, staging, prod and playstore across debug and release, minus playstoreDebug which does not exist. Only the app modules carry flavours, so switching environment rebuilds nothing in core, data or feature.
Release artifacts that are already named
build/outputs/distdistProdRelease gives per-ABI APKs plus a universal one, stamped with variant, ABI, version and build time, with a checksums file beside them. The bundle is a second task, because AGP refuses to build both at once.
Layering the build enforces
verifyModuleDependenciesfeature → feature and data → data fail the build rather than a code review. The rule that keeps a module graph acyclic is the one that stops being followed the week everyone is busy.
MVI that cannot interleave
MviViewModelEvents are queued and drained in order on one coroutine, so two of them cannot land between a read and a write of the state. LoadState is sealed, so there is no way to represent loading and errored at the same time.
Loading the options from the generator…
Questions
Is the project it gives me actually going to build?+
Yes, and that is checked rather than asserted. The template in the repository is a real Gradle project, and on every change CI generates four projects — every feature on, every feature off, and the lean and everything presets — and builds each one: a debug build, a shrunk release build, the unit tests, Android lint and the build's own guards. If one of those broke, the site would not have been deployed.
Why no Material?+
Material is a brand as much as a toolkit, and a design system built on it inherits both. Owning the components means the theme is the only thing that decides how anything looks: one hex changes every accent, one string changes every text style, one enum changes how every control answers a finger. An androidx.compose.material import fails the build, so it cannot creep back in.
What if I want a feature I turned off?+
Turning one off deletes its module rather than commenting it out, so adding it back means generating again or copying the module from the repository. Feature modules are different — add_feature.py scaffolds a new :data: and :feature: pair into a project that already exists and makes the three edits people forget, and remove_feature.py takes one back out again, including those same three edits.
Can it make my signing keys?+
Yes, if you ask — it is off by default. Keys made here are created on a server you do not control and sent back over the wire, which is fine for dev and staging and a real trade for a Play upload key, the one credential in Android whose loss cannot be undone. The Build step spells that out before you turn it on. The CLI makes all four on your own machine, and the README in every project has the keytool commands.
Do I have to use the components as they are?+
No — they are a starting point. Pick the design style closest to your app, then change the tokens and the components themselves until it looks like yours. They are ordinary Compose in your own module, not a library you have to wrap.
Does it work with AI coding agents?+
Every project ships an AGENTS.md (and a CLAUDE.md that points at it) describing the layout, the rules the build enforces, how a feature is shaped, and how to write code and comments the way the rest of the project does. The repository has its own, explaining how an agent can generate a project from a JSON spec without the wizard.
Which JDK do I need?+
Whatever Android Studio already has. Gradle runs on its bundled JetBrains Runtime or any JDK 17 or newer, and nothing downloads a second one. The code is compiled for Java 17.
Do you keep anything I typed?+
The app name, package, and which features you picked, so the popular ones can be made defaults and the unpopular ones deleted. No IP address is stored — visitor counts use a salted hash, and rotating the salt forgets who visited without losing the numbers. No cookies, no third-party analytics, and the generated project is never written anywhere but a temporary directory that is deleted as the download finishes.
Can I run this myself?+
All of it. The generator is a Python script with no dependencies, the API is one Go binary, and this site is a Next.js app. Everything is MIT.
Who made this
Sarthak Tripathi
Android developer. This started as the setup work at the front of every new project — the modules, the variants, the design system — done once properly instead of badly every time. It is all open source; issues, pull requests and arguments about the architecture are welcome.