How to double project throughput without expanding your team: the software house + GENESIS-AI collaboration model
GENESIS-AI is a research project in the inLABs programme. The capabilities described are research goals, not an available product. Project status: inLABs
Software houses have been living with the same paradox for years: in order to grow, you need to deliver more projects, and in order to deliver more projects, you need to hire more developers. Margins are eaten up by recruitment costs, turnover, and wage pressure, and management is constantly faced with the same dilemma: “take on another project or risk overloading the team?”
A collaboration model with an AI software factory could break this pattern. Instead of the classic “more people = more projects,” a software house can build a hybrid: people + AI software factory, where the platform takes on repetitive, low-level work, and the team focuses on what actually generates margin – analytics, architecture, integrations, UX, and maintenance.
Problem: growth that stifles margins
A typical scenario seen in many service companies:
- The sales pipeline is full, but delivery capabilities are limited by the number of available developers.
- The customer expects a shorter time-to-market and a predictable budget, and projects are becoming increasingly complex in terms of architecture (microservices, integrations, security, compliance).
- Even a well-organized team spends a significant amount of time on repetitive tasks: generating boilerplate, configuring layers, repetitive CRUDs, APIs, forms, lists, and validations.
As a result, the company grows “across the board”: more people, more projects, but the unit margin does not increase, and the operational risk does.
The role of
By design, GENESIS-AI is meant to: the concept of a full AI software factory in the SDLC
The GENESIS-AI project aims at a platform that will generate complete, multi-layered web applications from precisely described business requirements — from the data model, through the backend and frontend, to quality tests, security tests, and deployment packages (e.g., Docker images ready to run in Kubernetes). From a software house perspective, it is not about replacing the team, but about integrating GENESIS-AI into the existing SDLC as a factory that automates the entire process of producing applications in accordance with specifications, while people focus on what really generates margin: analysis, architecture, integrations, UX, and further development.
GENESIS-AI:
- accept a structured requirements specification (GENESIS-DOCU standard),
- design architecture and components,
- generate complete application code and automated tests,
- prepare containerised packages for deployment on the customer’s target infrastructure.
GENESIS-DOCU – fuel for the factory
The key to automation is meant to be the GENESIS-DOCU standard — a unified way of describing requirements that GENESIS-AI is meant to interpret without ambiguity. GENESIS-DOCU is meant to combine business process descriptions, diagrams (e.g., BPMN, UML), role and permission definitions, data models, and mockups/prototypes of key screens into a single coherent set of artifacts, which is a formal “contract” between the analysis and architecture team and the software factory.
Thanks to GENESIS-DOCU:
- analysts and architects work with tools and notations they are familiar with,
- the platform receives input in a precise, machine-processable format,
- any change in requirements can be quickly reflected in DOCU and the complete application can be regenerated, instead of manually rewriting large blocks of code.
Which SDLC elements to delegate to the platform
1. Requirements analysis → GENESIS-BIZSTORY → GENESIS-DOCU → input to GENESIS-AI
The partner team continues to conduct workshops with the customer, map processes, and design solutions at the business level — but instead of locking them down in classic “Word + Excel,” it uses the GENESIS-BIZSTORY mechanism (part of the project).
GENESIS-BIZSTORY is meant to hold conversations in natural language (moderated by agents specializing in UI, integrations, data models, and testing), ask probing questions, ensure consistency and validate requirement quality as it goes.
The result of this work is automatically generated documentation in the GENESIS-DOCU standard – a structured description of requirements that combines business process descriptions, diagrams (BPMN, UML), role and permission definitions, data models, and mockups of key screens.
Such a GENESIS-DOCU package is meant to be the input to the GENESIS-AI factory: precise enough for the platform to design the architecture and generate a complete application on its own, and at the same time clear enough for business, analysts, and architects to work on it normally and, if necessary, iteratively refine it.
In this way:
- there is no longer any manual “preparation in DOCU,”
- BIZSTORY is naturally integrated as the first step,
- DOCU is shown as an automatic but editable output that feeds the application factory.
2. Architecture and pattern design
The architect on the software house side selects the target architecture style, technologies, integrations, and non-functional constraints. GENESIS-AI treats this as a “bus” – based on these assumptions, it designs and generates:
- the structure of modules and services,
- API contracts,
- communication layers,
- integrations with databases and external systems.
The partner continues to sell architectural expertise – only the speed of transition from the model to a working application compliant with the adopted architecture and ready for further development increases.
3. Application code generation
The greatest leverage effect occurs when generating:
- screens and forms (including validation and UI status),
- CRUDs and business operations,
- process flows (workflow),
- reports, lists, filters, notifications.
On this basis, GENESIS-AI is meant to create a consistent, complete web application compatible with GENESIS-DOCU – with a data layer, backend, frontend, security mechanisms, and tests – and the development team takes it over for further customization and integration, instead of writing everything from scratch.
4. Quality and security testing
The platform automatically:
- generates some of the tests (e.g., unit tests, E2E scenarios for critical paths),
- performs static code analysis,
- checks compliance with selected security guidelines.
The QA team does not disappear – it shifts toward exploratory testing, non-functional testing, edge scenarios, and business testing.
How does a software house continue to make money?
In the hybrid model, the software house’s revenue would no longer be based on simple developer billing, but rather on the value delivered around the GENESIS-AI factory and repeatable product packages.
The key revenue streams are:
- Business and product analysis – workshops, discovery, scope clarification, function prioritization; this is where decisions are made about what will actually go into GENESIS-DOCU and what solution variants are worth generating.
- Architecture and technical design – selection of architecture style, patterns, integration, cloud, security; the software house sells its expertise in designing solutions that the factory would quickly turn into a working application.
- Integrations and edge cases – connecting existing systems, non-standard components, domain-specific logic that does not make sense to generate; this is an area where deep technical and domain knowledge is still needed.
- UX/UI and product design – designing user experience, micro-interactions, and product advantages that distinguish the solution from a “typical” template-generated application.
- Maintenance, development, and ops – DevOps, SRE, monitoring, development roadmap, change requests; with a software factory, further functionality could be planned as iterations at the GENESIS-DOCU level, rather than just manually adding code.
- Productized services and IP – as similar projects are implemented, the software house can build its own DOCU libraries (process patterns, data models, UI) and sell them as semi-finished products or accelerated implementation packages for selected industries.
As a result, the share of revenue from high-margin expert services, productized services, and maintenance would grow, while the share of low-margin “code writing” is decreasing. The same number of developers could handle more projects if a factory such as GENESIS-AI took over the heavy, repetitive work, and people focus on what the customer is really willing to pay more for.
Cooperation model: step by step
The following steps describe how to move from customer discussions, through GENESIS-BIZSTORY and GENESIS-DOCU, to a complete application to be generated by GENESIS-AI.
Step 1: identification of “factory” project types
We expect the greatest business impact in projects dominated by business processes and data operations — there the platform could generate virtually the entire application, and the team focuses on integrations, UX, and elements that distinguish the product from the competition.
Step 2: Standardization of input artifacts
The software house adopts GENESIS-DOCU as a common standard for describing requirements for projects implemented using the GENESIS-AI factory. This means consistent rules for how we describe business processes, how we model data, how we define roles and permissions, and how we prepare screen prototypes – all in a single, unified format that serves as a contract between the team and the platform.
Such standardization:
- eliminates documentation chaos between projects,
- speeds up the start of each subsequent implementation, because analysts work according to a repeatable template,
- is meant to enable GENESIS-AI to generate complete, consistent applications without the need to manually “translate” requirements into technical tasks.
Step 3: Integrating the pipeline with GENESIS-AI
In practice, this means:
- implementing a workflow in which, after the analysis/architecture stage, the project goes to the “factory” as a set of artifacts,
- integration with the code repository and CI/CD process,
- determining which modules are generated and which are always written manually.
The team receives the generated application directly in the repository – with full code, tests, and configuration, ready for further customization, integration, and development.
Step 4: Tuning and development
Developers focus on:
- adding custom logic,
- optimizing key fragments,
- integrations that require domain knowledge,
- refining UX and edge cases.
In subsequent iterations, some changes can be fed back into the models and regenerated — instead of rewriting larger blocks of code.
Business effect: how to “double throughput”
A software house that has implemented such a model can:
- Maintain the current size of the team, yet increase the number of parallel projects (some of the work is taken over by the factory).
- Shorten project start-up time: it takes weeks, not months, to go from requirements to a working first version of the MVP.
- Improve cost predictability – it is easier to estimate the scope of manual work when a large part of the application is created according to a repeatable pattern.
- Improve the quality and consistency of solutions, because the architecture and patterns are generated according to a uniform standard.
Combining the standardised GENESIS-DOCU specification with the application-generation automation we research in the GENESIS-AI project is meant to let the same number of people handle more projects with a similar profile – with shorter time-to-market and higher quality repeatability. This is not a promise of “magical” growth but a model we are testing in our research: each project starts from the same structured input (DOCU) and ends with a generated application, and the team focuses on what the customer is willing to pay the most for – domain expertise, integrations, UX, and further development of the solution.
This means that a software house can realistically double its project throughput in selected types of orders – without linearly adding more FTEs.
Who is this model for?
- For software houses that have a steady influx of similar projects (e.g., in a specific industry or domain) and want to build their own “productized services” model.
- For companies that feel their teams are too expensive to waste their time generating boilerplate, yet do not want to relinquish control over architecture and quality.
For organizations that want to build a competitive advantage: instead of competing only on price and number of FTEs, they offer a shorter time-to-market while maintaining enterprise quality.