Production-ready Java backends, generated from your SQL schema. Hours, not months.

Yes. It’s used only to build your backend, treated as confidential, and an NDA is available on request.

Your SQL schema to start: the structure (tables, relationships, constraints), not your data or business logic. From there we run a short guided session to capture the domain choices that shape the output: microservice boundaries and their names, whether you want MongoDB / Redis / the outbox pattern, environment profiles, and so on. You bring the domain; we handle the technical translation.

A production-ready backend for every entity: hexagonal, tested, runnable. Your business logic and integrations stay with your team. The code is fully yours, no lock-in.

Your choice, from the same domain: a modular monolith or microservices (one runnable Spring Boot app per module). No rewrite when you switch.

No. The factory stays proprietary. You receive the output: professional, tested code you own entirely and can maintain without AlveoForge.

Per-project, priced on your schema (size and complexity), not per table. The first payment is a down-payment: you see your backend running on your schema, with its Swagger and test reports, before you pay anything. As a yardstick, the same structural layer built in-house is six to ten months of a team.

You do, completely. Modify it, deploy it, extend it, reuse it in other projects. No licence fee, no royalties, no runtime dependency on us. The only thing that stays ours is the generator itself.

It’s used only to build your backend, kept confidential, and deleted after delivery. Never shared with third parties or used to train anything. Prefer to send an anonymized/renamed schema (structure without real names)? That works too.

The code is yours with zero dependency on us: standard Maven, standard Spring Boot. It keeps building, running and staying maintainable whether we’re around or not. That independence is the continuity guarantee.

Real hexagonal with vertical slicing: business logic isolated from database, framework and delivery. It’s the whole reason the factory exists: AI-assisted teams drift toward layered MVC; this doesn’t.

As a four-layer test pyramid: the industry-standard taxonomy (Fowler / Clemson), each layer its own Maven profile. Unit tests every class in isolation with its collaborators mocked, fast and deterministic, the default run. Integration exercises the persistence adapters against a real database (PostgreSQL, MongoDB, Redis) spun up with Testcontainers, not an in-memory stand-in. Component boots the whole service on a random port and drives it through its HTTP boundary: JSON contract, status codes, validation, live schema. End-to-end runs a full user journey with every collaborator real, including outbox propagation and email verification. There’s deliberately no consumer-contract layer: the OpenAPI/Swagger spec is the contract, and the component layer verifies it.

Methods, lines and branches, measured with JaCoCo. Every path is executed and asserted, not just run. Test strength is verified with mutation testing (PIT): it injects faults into the code and checks the tests catch them, at a 95%+ mutation score.

Both. Every endpoint is tested for success and for failure: 400 validation, 401 auth, 404, 415, error paths included. Across the four-layer pyramid, asserting methods, lines and branches. Empty happy-path tests are exactly what we don’t ship.

Full CRUD plus batch: create, read (single, paged, by-ids), update, delete, create-many and bulk updates, with read-time relationship expansion (?expand=…) across slices, no N+1 queries and no JPA object graph leaking across layers.

Your DDL is the single source of truth, emitted as a versioned migration. Pick Flyway or Liquibase, both wired with parity, or point it at an existing production database and it adapts (brownfield) without rebuilding your schema. Hibernate runs in validate mode, so entities are checked against the real schema at boot.

Yes. One pattern repeated consistently, standard readable code any Java dev extends from day one, plus a 30-day support window. And you own it: no dependency on AlveoForge.

Regeneration reproduces the factory version of an entity, so manual edits to that same slice are overwritten. In practice you regenerate to add new entities: because each one is an independent vertical slice, new slices drop in alongside the code your team already wrote and edited, without touching it. Your business logic lives in its own slices and stays intact.

No. The output is a standard Maven project: open it in any IDE (IntelliJ, VS Code, Eclipse, NetBeans…) or in none at all. Build, test and run it straight from the terminal with the Maven wrapper (./mvnw). No editor, plugin or vendor lock-in.

Java 25, Spring Boot 4.1, hexagonal + vertical slicing, PostgreSQL · MongoDB · Redis with outbox, JWT auth, dev / pre / prod profiles.

The full breadth of standard PostgreSQL types: arrays, enums, JSONB, UUID, the date/time family (date, time, timestamptz), numeric and decimal precision, binary (bytea), varchar/char length validation, composite and foreign keys, plus table inheritance and declarative partitioning. And generation never fails on a type it doesn’t recognize: it falls back to a safe default (string) that your team can refine later, so you always get a running backend. We flag any such column together in the kick-off, no surprises. That’s why the process is guided.

We can work from an anonymized/renamed schema (structure without real names) or under a tripartite NDA. On-premise isn’t offered: the factory never leaves.

Yes. New modules are generated as independent vertical slices and added alongside your code, without touching what your team already built.

Yes. Deterministic output means the same structure every time, so developers rotate between projects with no ramp-up.