Four lessons from building AI, education, and healthcare products with Next.js

Robert Ionut Fundulea — Mon, 27 Jul 2026 19:20:30 +0000

Over the last few years, I have built products in very different domains: generative AI, job search, education, and clinic operations.

Although the interfaces and users are different, several engineering lessons appeared repeatedly.

1. Multiple AI features still need to feel like one product

Klyro brings together streamed chat, cited web search, image analysis, and image generation.

The difficult part was not simply connecting several AI services. It was creating one consistent experience around them: shared authentication, one responsive interface, predictable errors, subscriptions, billing, and a transparent credit balance.

For every operation, Klyro estimates the cost, reserves the required credits, and settles the balance according to actual usage. When an operation fails, the reserved credits are released.

Live product:
https://www.klyroai.net

2. AI should assist important decisions, not hide them

RoleMint is a job-search copilot that discovers opportunities, compares them with a candidate’s profile, generates ATS-oriented materials, and organizes applications in a visual pipeline.

The user remains responsible for reviewing and approving every generated application. That human checkpoint is important when AI-generated content represents someone professionally.

https://rolemint.vercel.app

3. A learning platform starts with its data model

BrightLearn supports lessons, categories, tags, quizzes, questions, answers, attempts, scoring, and progress history.

It was built with Next.js, TypeScript, Prisma, PostgreSQL, Clerk, and AI integrations. Designing the relationships between learning content and user attempts was just as important as building the interface.

BrightLearn is open source:
https://github.com/RobertIonutF/brightlearn

Application:
https://medilearn-rose.vercel.app

4. Operational software needs traceability

FizioKinetoMaxim is a protected CRM for clinic operations. It centralizes patients, appointments, medical and administrative activity, CAS cases, exercise programs, feedback, reports, incidents, complaints, and audit history.

The application uses Next.js, TypeScript, and Convex for reactive data and real-time workflows. Role-based access and traceability were essential because the application handles sensitive operational processes.

https://fiziokineto-maxim-crm.vercel.app

Building similar products

I work on complete SaaS products, AI integrations, CRM systems, educational platforms, and operational dashboards.

If you need something similar, you can contact me through LinkedIn:
https://www.linkedin.com/in/robertionutfundulea/

You can also support my independent projects here:
https://buymeacoffee.com/robertfundulea

A Bug Triage Workflow for AI That Does Not Invent the Root Cause

Robert Ionut Fundulea — Tue, 21 Jul 2026 18:19:17 +0000

AI can make bug triage faster, but it also makes one dangerous failure mode easier: turning a plausible explanation into a confident diagnosis before the failure has been reproduced.

The useful question is not “Can the model suggest a cause?” It usually can. The question is: what evidence would let another developer review that cause?

Here is the workflow I now use for AI-assisted bug work.

1. Turn the report into an actionable record

Capture the build, environment, user path, expected behavior, actual behavior, frequency, impact, and any existing evidence.

Keep observations separate from interpretations. “The request returned 500 at 14:32” is evidence. “The database timed out” is still a hypothesis unless the logs support it.

If a material fact is missing, the workflow should ask for it. It should not silently fill the gap.

2. Reproduce—or document bounded non-reproduction

A good reproduction record includes:

the exact setup and version;
inputs and relevant timestamps;
ordered actions;
expected and actual output;
logs, screenshots, or traces;
the control case that still works.

When the issue does not reproduce, return the matrix that was tested and name the next signal needed. “Could not reproduce” is not the same as “the bug is invalid.”

3. Compare the failing path with a working control

A nearby working path is often more useful than reading the entire codebase.

Consider a fictional scheduling defect: patients can double-book a physical slot near the spring daylight-saving transition, but only when rescheduling in Europe/Bucharest.

The new-booking path normalizes local time through a timezone-aware scheduling boundary. The reschedule path compares a naive local value directly with stored UTC instants.

That comparison gives us something much stronger than “timezones are hard”: a narrow difference between a failing path and a working control.

4. State the smallest evidence-supported cause

A useful cause statement has three parts:

Condition: rescheduling across the DST boundary.
Mechanism: a naive local timestamp is compared with stored UTC instants.
Evidence: the failing path skips normalization while the working booking path uses it.

Also record alternatives that were ruled out and those that remain untested. This prevents a narrow finding from becoming an unsupported claim about the whole system.

5. Repair the authority boundary, not the symptom

The minimal repair is to route rescheduling through the existing timezone-aware normalization function before collision checks.

It is not to weaken collision rules globally, disable validation near DST, or rewrite every scheduling path.

Minimal does not mean careless. It means correcting the supported cause with the smallest reasonable regression surface.

6. Protect the invariant

The regression test should fail for the original defect and prove the behavior that matters:

equivalent instants cannot reserve the same physical slot;
the DST gap is handled according to the product rule;
adjacent slots still work;
ordinary dates remain unchanged;
the new-booking control path stays green.

Then add rollout signals and a recovery path appropriate to the risk. A local test does not prove production repair.

A compact review checklist

Before accepting an AI-assisted diagnosis, ask:

Do we know the exact environment and build?
Is expected behavior stated independently of the implementation?
Was the failure reproduced, or was non-reproduction bounded?
Is there a working control path?
Does the cause statement connect condition, mechanism, and evidence?
Does the proposed change preserve unrelated policy?
Does the regression test protect the invariant rather than mirror the code?
Are rollout and recovery signals explicit?

AI is valuable here as a structure and comparison tool. It can organize evidence, propose a reproduction matrix, compare paths, and draft regression cases. It should not claim a root cause, test result, or production behavior it has not observed.

I published a free, read-only walkthrough with the worked timezone example here:

AI Bug Triage Workflow: From Report to Minimal Fix

I built CodeCurrent Studio and may benefit if someone buys one of its workflow packs. The walkthrough above is free. CodeCurrent Studio is independent and is not affiliated with or endorsed by any AI model vendor.

DEV Community: Robert Ionut Fundulea