1. SPECIFY
MVP features from research
Clear product requirements
Prompt becomes build blueprint
D2 Automation Systems
Public case study 11
Product PrototypingAI-assisted no-code SaaS MVP
D2 publishes architecture, implementation evidence and evidence boundaries separately so the reader can distinguish demonstrated system design from unverified production outcomes.
Read D2 evidence methodology n8n Automation PortfolioSelected AI product case study
D2 Group · Selected AI product case study
ZenCal
AI-Assisted No-Code SaaS MVP
A rapid SaaS prototyping exercise focused on product decomposition: analyze an existing scheduling product, define the smallest useful feature set, convert that scope into a build specification, then test and debug the working application.
PerplexityLovable.devProduct ResearchMVP ScopingFull-Stack PrototypingFunctional Testing
2
AI / no-code tools
1
Full-stack MVP
3
Core validation areas
E2E
Idea → working flow
Role
AI Automation Engineer / Rapid Product Prototyper
01 / Product decomposition
Start by deciding what deserves to be built.
The project did not begin with ‘generate me a scheduling app.’ It began by reducing an existing product into an MVP scope.
Starting question
What are the essential capabilities of a Cal.com-style scheduling product, and which of them are required to prove a usable MVP?
01
CAL.COM AS REFERENCE
Existing product used to understand the problem space
02
PERPLEXITY: FEATURE ANALYSIS
Identify scheduling, booking management, dashboard and MVP-level capabilities
03
MVP SCOPE
Remove non-essential complexity and keep the flows needed to prove the product
04
BUILD SPECIFICATION
Turn product understanding into a structured instruction for the app builder
02 / AI-assisted build loop
From specification to a working full-stack prototype.
The scoped product prompt was moved into Lovable.dev, which generated the application experience and connected frontend, backend, database and user-management behavior inside the same environment.
2. GENERATE
Lovable creates the app
Frontend + backend
Data and user flows connected
3. TEST
Sign-up / login
Dashboard access
Core feature behavior
Why this is not just “prompt and pray”
Generation was only the first pass. The application was immediately tested against the product flows defined earlier. A generated interface is not considered complete until the behavior behind it works.
Use research to reduce ambiguity before generation.
Treat the initial AI build as a prototype that must be verified.
Validate behavior, not only visual output.
03 / Debugging & functional validation
The useful part starts when the generated app breaks.
The first user-management flow did not work correctly. The issue was traced to the application/backend not being able to access the user database as expected, so the connection/settings were adjusted and the flow was tested again.
Initial issue
User-management / database access did not behave as expected during testing.
Configuration fix + retest
The connection/settings were corrected and the dashboard flow was validated again.
End-to-end validation
A prototype is working only when the critical action completes and the resulting state can be verified.
ACCOUNT FLOW
Sign-up
Login
Reach user dashboard
BOOKING FLOW
Create / use booking link
Complete sample booking
Confirm scheduled meeting
DATA FLOW
Open booking history
Verify stored booking
Confirm persistence
Validation rule
A SaaS prototype is not “working” because the screens exist. It is working when the critical user action completes and the resulting state can be verified afterward.
04 / Product & automation mindset
What this small project is meant to demonstrate.
Not the size of the SaaS. The value is the repeatable process used to move from an existing product idea to a validated functional MVP.
01
Decompose before building
Analyze the reference product, identify the minimum useful capabilities and avoid rebuilding complexity that is not required for the test.
02
Use AI in distinct roles
One tool helps research and structure the problem; another accelerates implementation. Each supports a different stage.
03
Convert ideas into specifications
A stronger build prompt starts from explicit product requirements rather than a vague request to generate an application.
04
Test the complete user journey
Validate authentication, dashboard access, booking execution and stored booking history instead of stopping at a rendered UI.
05
Debug the system, not the screenshot
When user management failed, the work moved to the backend/data access path, then the flow was retested.
06
Optimize for learning speed
AI-assisted builders are useful when they shorten the distance between product hypothesis and a working, testable system.
“Use AI to shorten the build loop — not to skip product reasoning.”
Research → scope → specify → build → test → debug → validate.
RESEARCH
Understand the product
SCOPE
Define the MVP
BUILD
Generate rapidly
VALIDATE
Prove the flow
Final takeaway
Research → scope → specify → build → test → debug → validate is the repeatable system behind the prototype.
D2 Automation Systems
Need a system designed around a real operating constraint?
D2 maps the process, source of truth, deterministic rules, failure paths and evidence boundary before recommending the automation scope.