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

AI / no-code tools

Full-stack MVP

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?

CAL.COM AS REFERENCE

Existing product used to understand the problem space

PERPLEXITY: FEATURE ANALYSIS

Identify scheduling, booking management, dashboard and MVP-level capabilities

MVP SCOPE

Remove non-essential complexity and keep the flows needed to prove the product

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.

1. SPECIFY

MVP features from research

Clear product requirements

Prompt becomes build blueprint

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

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.

Decompose before building

Analyze the reference product, identify the minimum useful capabilities and avoid rebuilding complexity that is not required for the test.

Use AI in distinct roles

One tool helps research and structure the problem; another accelerates implementation. Each supports a different stage.

Convert ideas into specifications

A stronger build prompt starts from explicit product requirements rather than a vague request to generate an application.

Test the complete user journey

Validate authentication, dashboard access, booking execution and stored booking history instead of stopping at a rendered UI.

Debug the system, not the screenshot

When user management failed, the work moved to the backend/data access path, then the flow was retested.

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.

Back to portfolio