AI can produce output without evidence
A technically impressive build is not necessarily evidence that the right problem was identified or the right product was scoped.
Zorentia for universities
Give every student project a structure.Keep student judgement at the centre.
For capstones · incubators and accelerators · innovation programs · build-focused hackathons
Zorentia guides students from an initial idea and real customer evidence through MVP scope, system architecture, implementation, user testing and launch.
Students use AI to create and examine technical artifacts, but they remain responsible for what should be built, how it works, what was tested and whether it is ready to move forward.
Program leads manage student access and see cohort participation, recorded stages and credit usage, without automated grading or access to private project content.
- 01Idea
- 02Evidence
- 03MVP
- 04Architecture
- 05Implementation
- 06User testing
- 07Launch
Used at Macquarie University Incubator
“A great tool to assist non-technical founders in building technical MVP / prototypes, making technical decisions, and determining the order of builds.”
Macquarie University Incubator uses Zorentia across its START and EDUCATE programs. START founders use it to frame problems and scope MVPs. EDUCATE founders use it to work through architecture and engineering decisions.
Read the Macquarie University Incubator storySoftware education in the age of AI
Generating code is easier. Understanding what was generated still matters.
Students can now produce code before they understand the problem, the scope, the system behind it or how to verify that it works.
For universities, the challenge is no longer simply giving students access to AI. It is designing a process in which students must make their reasoning visible, confront real constraints and remain accountable for the result.
Different projects become difficult to supervise
When every team is building something different, staff need a common process without forcing every project into the same solution.
A finished interface can conceal unfinished thinking
Architecture, data design, backend behaviour, testing and deployment can disappear behind a polished generated screen.
Zorentia gives every project the same sequence of decisions while allowing each student or team to pursue a different idea.
One pathway. Different projects.
Students do not just ask AI to build an app. They work through the decisions that make an application coherent.
Each stage begins with the artifacts produced earlier. Customer evidence informs feature selection. Approved features inform MVP scope. MVP scope informs architecture. Architecture informs the database, backend and interface.
The result is a connected project process rather than a collection of disconnected prompts and generated files.
Programs can stop at the artifact that matches their learning outcome. Not every student needs to complete or deploy a full application.
- 01Idea
- 02Evidence
- 03MVP
- 04Architecture
- 05Implementation
- 06User testing
- 07Launch
Choose the depth your program requires
Plan the product, or continue through the complete build process.
01
Planning pathway
From an idea to a build-ready technical plan
For incubators, early-stage innovation programs and subjects focused on product definition, evidence and technical planning.
Students work through
- 01
Defining the problem, intended user and proposed solution
- 02
Creating an editable product pitch
- 03
Collecting or importing feedback from real people
- 04
Checking proposed features against reported customer problems
- 05
Selecting the smallest viable first release
- 06
Sequencing what belongs now, next and later
- 07
Mapping each approved feature across data, backend behaviour and screens
Student outputA defined product, recorded customer evidence, evidence-linked feature decisions, MVP scope and connected system architecture.
02
Build pathway
From an approved plan to a generated application package
For capstones and build-focused programs where students need to continue from technical planning into implementation, testing and deployment.
Students work through
- 01
Preparing their development environment
- 02
Creating a private GitHub repository
- 03
Generating and reviewing a MySQL schema
- 04
Generating and reviewing Flask backend routes
- 05
Generating and previewing HTML and Tailwind application screens
- 06
Assembling the frontend and backend into a downloadable package
- 07
Running the generated application and tests locally
- 08
Conducting moderated user-testing sessions
- 09
Following guided deployment, domain, DNS and HTTPS steps
Student outputA generated full-stack package connected to the approved architecture, plus the student’s own implementation, testing, user-research and deployment work.
From generated package to working application
Zorentia checks the generated package structure and technical contracts. Students then take ownership of running the application, reviewing its behaviour, resolving implementation issues and deciding when it is ready to deploy.
What students actually do
Seven stages. A different responsibility at every stage.
01
Define the product
Students explain the problem, audience, proposed solution, business model, available evidence and what they need next. Zorentia helps strengthen unclear answers and produces an editable pitch.
Student responsibility
Supply accurate information, question generated assumptions and decide what the product is actually claiming.
02
Collect evidence
Students publish or share their product pitch, collect responses from real people or import existing customer feedback, and describe the features they are considering.
Student responsibility
Find appropriate participants, collect genuine responses and judge the quality and limits of the evidence.
03
Decide what belongs in the first release
Zorentia compares proposed features with reported customer problems and helps students turn approved features into a sequenced MVP.
Student responsibility
Decide whether the evidence is convincing, remove unsupported features and accept the trade-offs required by the available time.
04
Design the system
Students work through every MVP feature in order: database structure, backend functions and routes, then application screens and actions.
Student responsibility
Review the proposed components, understand how they connect and regenerate or revise decisions that do not fit the intended product.
05
Generate and integrate the implementation
Zorentia translates the approved architecture into database, backend and frontend files and assembles them into a downloadable application package.
Student responsibility
Inspect the files, configure the environment, run the application locally, execute tests and resolve issues rather than treating generation as proof of correctness.
06
Test with real people
Zorentia creates testing goals and realistic tasks from the active MVP. Students then moderate sessions with three participants and record outcomes, time, blockers, quotes and observations.
Student responsibility
Recruit relevant participants, avoid leading them, record what actually happened and decide which problems should be addressed next.
07
Take the application toward launch
Guided steps cover repository preparation, server deployment, domain configuration, DNS and HTTPS.
Student responsibility
Create and manage external accounts, review costs and security decisions, execute the deployment steps and verify the live application.
Program-lead visibility
See participation across the cohort without turning activity into a grade.
Program administrators can organise students into cohorts, manage access and identify where attention may be useful.
CAPSTONE STUDIO · SEMESTER 2
University cohort overview
Program lead view Illustrative interface · fictional data
Cohort movement
8 project teamsSee membership, activity, milestones, shared credit use and recent project movement in one place.
Program at a glance
Membership
32 students · 8 teams
Active
7 teams this week
Project movement
Recent activity01
Project team 01Active
4 members
Evidence
2/7
02
Project team 02Active
4 members
System
4/7
03
Project team 03Needs attention
4 members
Build
5/7
04
Project team 04Not started
4 members
Idea
1/7
Cohort context
Current movement
Most teams are moving from evidence and MVP scope into system design.
Shared allocation
427 of 1,000 credits used
Shared project route
- 1
Idea
- 2
Evidence
- 3
MVP
- 4
System
- 5
Build
- 6
Test
- 7
Launch
Activity signals, not grades
Signals show participation and project movement. They do not grade work or replace university judgement.
Student work remains private
Program leads see participation and pathway progress. Student code, raw project inputs and generated artifacts remain private to the student.
This gives staff an early view of where support may be useful without turning activity into a grade or replacing academic supervision.
What the university gains
A common process for projects that do not all look the same.
A clearer project structure
Every student moves through the same categories of work: evidence, scope, architecture, implementation, testing and launch.
More explicit student decisions
Students encounter defined points at which they must select features, review technical structures, interpret evidence and decide what happens next.
A manageable cohort layer
Administrators can create cohorts, invite students individually or by CSV, monitor participation signals and manage access from one organisation portal.
Flexible program depth
One program can stop at product definition and technical planning. Another can continue through generated implementation, user testing and guided deployment.
Student-owned work
Students retain ownership of their original inputs and work and receive rights to use generated outputs under the applicable Terms.
Where Zorentia fits
Use the parts of the pathway that match the program outcome.
Incubators and accelerators
Help student founders move from a broad opportunity to customer evidence, a constrained MVP and a technical plan before committing heavily to implementation.
Capstone and project courses
Give different student projects a common sequence from scope and architecture through implementation and verification.
Innovation and entrepreneurship programs
Connect product thinking with the technical decisions required to turn an idea into something buildable and testable.
Hackathons and intensive programs
Give teams a defined route for narrowing scope, identifying the core demonstration and recording the system behind it.
The appropriate pathway depends on program duration, student experience, available devices, external accounts and the artifact students are expected to produce.
Bringing Zorentia into a program
Start with the outcome, not the number of tools.
- 01
Define the program outcome
Your university providesProgram format, student profile, cohort size, dates, academic requirements and the expected final artifact.
Zorentia providesA recommended pathway based on whether students should finish with product evidence, a technical plan, a generated application package or a guided launch process.
- 02
Create the organisation and cohort
Your university providesEligible student email addresses and the staff who require organisation-administrator access.
Zorentia providesOrganisation access, cohort administration, student invitations, cohort allocation management and participation signals.
- 03
Invite students
Students receive institution-sponsored access. They do not purchase an individual subscription or provide personal payment information to join the university cohort.
- 04
Run the program
Your university providesTeaching, assessment design, authentication, moderation, academic integrity and decisions about whether student work meets the required standard.
Zorentia providesThe student workflow, generated artifacts, saved tool progress, organisation access controls and cohort participation signals.
- 05
Review and close
Administrators can export roster information, remove access and request cohort data deletion in accordance with the Privacy Policy.
Plan the cohort with confidence
Know what the full pathway involves before students begin.
Devices
The complete Build and Launch pathway requires a computer. Code review, terminal work and multi-step implementation are not designed for a phone-sized screen.
External accounts
Depending on the program outcome, students may need GitHub, a local MySQL-compatible environment, an AWS account, a domain registrar account and access to email.
External costs
Hosting, domain registration and other third-party services are separate from Zorentia access. Some services may require a payment method.
Technical stack
The current generated build pathway uses MySQL, Python and Flask, HTML and Tailwind, GitHub and an AWS-oriented deployment guide. Planning and architecture work can still be useful outside that stack, but generated implementation is not stack-agnostic.
Integrations
Student access is currently managed through Zorentia’s organisation and cohort portal. Integration requirements can be discussed as part of your university’s institutional review.
Cohort access and pricing
Choose the outcome your program needs.
The university receives one shared program allocation. Credits are consumed only when students use Zorentia and remain available for the agreed semester, cohort or program period.
Planning program
Complete technical plan
For programs where students need to turn an idea into something ready to build.
A$2,000500 creditsTypical output: ≈20 students completing a full app planBuild program
Working application
For capstones and build-focused programs where students implement, test and deploy software.
A$4,0001,000 creditsTypical output: 5–6 complete app buildsBuild program
Working application
For capstones and build-focused programs where students implement, test and deploy software.
A$10,0002,500 creditsTypical output: 12–16 complete app buildsBuild program
Working application
For capstones and build-focused programs where students implement, test and deploy software.
A$20,0005,000 creditsTypical output: 25–33 complete app buildsInstitutional responsibility
Give every stakeholder a clear view of how Zorentia fits.
Institution-managed access
The university controls which students and administrators are invited, how students are organised into cohorts and when access is removed.
Student project privacy
Organisation administrators receive participation, stage and credit-usage information, while student code, raw inputs and generated project artifacts remain private to the student.
Student ownership
Students retain ownership of their inputs and original work and receive rights to use generated outputs under the applicable Terms. They own what they build with the Service.
AI data handling
Zorentia uses third-party commercial AI APIs to generate relevant outputs. Zorentia does not use student project content to train its own AI models. Current provider and processing information is available in the Privacy Policy and should be reviewed as part of institutional due diligence.
Academic responsibility
Teaching staff retain responsibility for assessment, authorship checks and decisions about whether a student has met the required learning outcomes. Zorentia supports that process without replacing university judgement.
Data deletion
Institutional administrators may request cohort data deletion according to the process and timeframe described in the Privacy Policy.
Common questions
What university teams usually need answered.
Which university programs does Zorentia fit?
Zorentia is best suited to capstones, incubators, accelerators, innovation programs and build-focused intensives in which students pursue different software ideas but benefit from a common project process.
Does every student need to build and deploy a complete application?
No. A program can stop after evidence, MVP scope or system architecture. Programs that continue through implementation require more time, a computer, local development work and relevant external accounts.
What can program administrators see?
Administrators can see student access status, cohort membership, engagement state, furthest recorded stage, last activity and credit usage. They do not see student code, raw inputs, generated artifacts or automated quality scores through the organisation portal.
Does Zorentia assess or grade student work?
No. Zorentia records workflow activity and produces project artifacts, but teaching staff remain responsible for assessment, authentication, moderation and academic judgement.
How does Zorentia keep students responsible for AI-assisted work?
Understanding is demonstrated by the student. Zorentia creates repeated points where students must provide evidence, approve scope, review architecture, inspect implementation, run tests, observe users and explain the decisions they made. Universities can use those artifacts within their own demonstration and assessment requirements.
How does customer evidence enter the workflow?
Students collect or import feedback from real people. Zorentia then helps them compare proposed features with the customer problems contained in that evidence.
How do students take an application toward launch?
Zorentia provides generated application files and a guided deployment pathway. Students configure the relevant external accounts, execute the steps and verify the application themselves.
What technology does the generated build use?
The current Build pathway generates a MySQL database, Python and Flask backend, and HTML and Tailwind frontend. The launch guidance is oriented toward GitHub, AWS, Nginx, systemd, domains, DNS and HTTPS.
How does student access work with university systems?
Student access is currently managed through Zorentia’s organisation and email-invitation system. If your university has LMS, identity or roster requirements, we can identify those needs with your team during institutional review.
How are students added?
Administrators can invite students individually or upload a CSV containing student email addresses. Students receive access to the university-managed cohort.
Do students need to provide payment details?
No. Students invited through an institution-sponsored organisation account do not purchase their own subscription or provide payment details to join the cohort.
How are cohort credits managed?
The university receives one shared program allocation. Credits are consumed only when students use Zorentia and remain available for the agreed semester, cohort or program period.
What can our privacy or procurement team review?
Universities can review Zorentia’s Privacy Policy and Terms and discuss specific security, privacy, data-handling, accessibility and procurement requirements before purchase. Requirements that are not currently supported should be identified before the program begins.
Your next cohort
Start with what students need to demonstrate. Then choose the pathway that gets them there.
Bring us your program format, student profile, cohort size, dates and expected final artifact.
We will show you the exact student workflow, the organisation view, the technical requirements and the access model that would apply to your program.
Program format · Student level · Cohort size · Dates · Expected artifact