Disclosure: I work on marketing for Hyde, the tool in this post. I tested it on a second small app, picked because date math is easy to check by hand and easy to get wrong.
Hyde (https://hyde.pixelverse.tech) is a chat-based app builder: you describe an app, and it writes the code and shows a live preview.
The prompt
A days-between-dates calculator: two date pickers (start and end), a checkbox to include the end date, and a clear result showing the number of days, plus weeks and leftover days.
What it did
It edited src/pages/Index.tsx, src/index.css and index.html, then reported that the app builds and renders without errors. The chat showed 1 minute 42 seconds of work and 1 credit on the free plan (my balance went from 5 to 4). The page it made has two date pickers, an "Include end date" checkbox, a swap button, a reset button, and a result panel. It chose its own name and styling, and it filled in default dates (June 1 to July 15, 2026).
The seven cases I checked
I typed each pair into the preview and compared with a hand count.
| Start | End | Expected | Shown |
|---|---|---|---|
| 2026-06-01 | 2026-07-15 | 44 days (6 weeks + 2 days) | 44, 6 weeks + 2 days |
| 2026-02-27 | 2026-03-01 | 2 days (2026 is not a leap year) | 2 |
| same, "include end date" ticked | 3 | 3 | |
| 2028-02-28 | 2028-03-01 | 2 days (2028 is a leap year) | 2 |
| 2026-03-08 | 2026-03-09 | 1 day (a US clock-change date) | 1 |
| 2026-06-01 | 2026-06-01 | 0 | 0 |
| 2026-01-01 | 2026-12-31 | 364 days (52 weeks + 0) | 364, 52 weeks + 0 |
All seven matched. The clock-change date is a classic trap for date math, and this one came out right.
I also entered an end date before the start date. It showed the absolute difference (44 days) and added a note: "Your end date is before your start date. We show the absolute number of days between them." That is a choice you might not want, but at least it tells you.
What didn't line up
After the build, the editor showed a red "Build error" banner pointing at /src/pages/Index.tsx ("hasn't been transpiled..." was cut off in the banner), and the console counter showed 6. The chat message said the build was verified and the preview worked, and every case above rendered correctly. I didn't click "Try to fix", so I can't tell you what the error was or whether it affects a published version. I'm only reporting that the banner and the "verified" message appeared together.
What I did not test
Publishing, a custom domain, GitHub sync and the built-in backend. This was one prompt and one project, so it says little about larger apps.
Takeaway
For a small, well-defined calculator, one plain-English message produced correct results on the date cases I picked. I would still run the boundary cases yourself: month ends, a leap day, equal dates, reversed dates.
Which date case do you always test first?
Top comments (1)
The one I always test first is a range crossing midnight in a timezone behind UTC. new Date('2026-03-08') parses as UTC, so in some zones it displays as the 7th and your count is off by one. Reversed dates showing the absolute difference with a note is a reasonable call, I like that it tells you.