gadr90

I tried to build and sell a CMS and frontend-as-a-service for 3 years. We "failed" as in not-rocketship-revenue. Now we are on board the software factory train and we are _replacing_ the services companies that used to operate our software. Now we are growing 20x faster. Welcome to the brave new world of Service as Software, I guess! Testing this mostly in Brazil/enterprise, launching support for Shopify this month.

I spent around two days vibecoding my new blog to talk about my adventures in post-LLM software development land.

I wanted to start by organizing my bookmarks and curating them with AI. So I built a tiny "workflow" (in the frontend) coordinating a local MCP Mesh with MCP servers for Perplexity, Firecrawl and Open Router. Twas fun to build and now I import every cool URL into it :)

Its also open source if anyone cares to see how it's built https://github.com/vibegui/vibegui.com

We have been building an open source CMS based on TypeScript for a while now at https://github.com/deco-cx/deco

Now we are adding the ability to deploy workflows and agents. It can _also_ code websites: https://decocms.com

But alas its not ready yet - pre launch this monday.

I asked ChatGPT to replace "current AI" and synonyms with "HUMANS" and I'm satisfied. My favorite revised sentences:

"Does HUMANS represent a dead end?"

"HUMANS should not be used for serious applications."

"HUMANS are unmanageable, and as a consequence their use in serious contexts is irresponsible."

"HUMANS have no internal structure that relates meaningfully to their functionality."

"HUMANS have input and state spaces too large for exhaustive testing."

"HUMANS do not allow verification by parts (unit testing, integration testing, etc)."

"HUMANS have faults, but even their error behaviour is likely emergent, and certainly hard to predict or eradicate."

"HUMANS have no model of knowledge and no representation of any ‘reasoning.’"

"HUMANS represent a dead end, where exponential increases of training data and effort will give us modest increases in impressive plausibility but no foundational increase in reliability."

"HUMANS cannot be developed, or reused, as components."

"There is no possibility for stepwise development — using either informal or formal methods — for HUMANS."

and my favorite:

"In my mind, all this puts even state-of-the-art HUMANS in a position where professional responsibility dictates the avoidance of them in any serious application."

Worse things have been said about them

That is true. Good docs, examples and community wins.

There are those who would say they created a "bait and switch" from their open framework into their closed for-profit deployment platform. That is not objectively wrong, though. But still, many complain. I say: good for them. Let competition happen.

I happen to be from Rio de Janeiro, Brazil, so I never met Nate — yet! But I'm pretty sure our paths will cross in the long long road of web development ahead of us :)

I am a fierce hater of the complexity and closed-ness which Next.js became, BUT "results don't have to be explained" and Mr. Guillermo unarguably executed the hell out of it. It IS the default for new frontend developers, right now. I don't think it will necessarily remain, specially because of things like One!

What the hell, Nate! As a long-time web developer who witnessed the divide between frontend and backend, this looks like the most transformative step forward since Next.js. What you have built here is amazing, and it's definitely something that the industry needs right now.

Me and my team have been working on a new Web Draw-first IDE that we're going to launch in a few weeks. And I just sent this thread to my engineering team demanding that they swiftly integrate One into our web draw, or they will walk the board! Just kidding. We're not really pirates. Anyway, amazing work, looking forward to using it for many projects here!!!

Hi Julien! I finally had the time to debug this and turns out it was trivial! We were missing a requestAnimationFrame, d'oh! Thanks for pointing it out, solved here: https://github.com/deco-sites/starting/pull/307

Hi @atonse! Finally had the time to debug this and turns out it was trivial! We were missing a requestAnimationFrame, d'oh! Thanks for pointing it out, solved here: https://github.com/deco-sites/starting/pull/307

Hi Orphea! Finally had the time to debug this and turns out it was trivial! We were missing a requestAnimationFrame, d'oh! Thanks for pointing it out, solved here: https://github.com/deco-sites/starting/pull/307

This is most likely the culprit! Will take care of it. Thanks for the detailed feedback <3

Hi n3storm! It means we account for how many pageviews your website is serving each month and we charge a variable amount based on that. That way you only pay for what you use. In the * asterisk, we end up defining a pageview as having a maximum of 10 requests, and you pay proportionally over that. In our experience, considering our SSR-first architecture and the fact that assets are immutably cached at the border, we've found most sites use less than 10 reqs per pageview.

Ouf, I'm not aware of it! Would love your feedback in a DM, perhaps Linkedin? https://www.linkedin.com/in/guifromrio/ Thanks for the input anyway!

Thank you! We need to start testing way more on Windows. Will do!

Thanks! Engineer capybaras are investigating as we speak :)

Thanks, Doctor! I was trying to use Deno in my previous company but they wouldn’t let me… so here we are :D

I’m looking forward to open-sourcing the admin UI soon and see what insane extensions people come up with on top of our stack!

Oh, that's terrible! Can you let me know your browser/OS combination? Seems like we've found a terrible performance bug for some combination that's quite common here in HN!

Hi, Julie! We're aware the current LP is not showcasing our focus on performance... but time is scarce in a tiny startup and we've spent it all optimizing the frontends of our customers :) we're going to improve that soon! Thanks for pointing it out. Looking forward for more feedback!

> Something something scroll hijacking.

I know, right? I'm also not super proud of that portion of the landing, lol!

> The biggest challenge I have found in integrating no-code and full-code lies in preserving changes made in full-code mode when updates are made in no-code mode.

God, YES! We've been working in this problem in one way or another for at least 10 years, and we also failed many times in solving that conciliation. We _think_ we have reached a good tradeoff now: _everything is on git_. So when you're using our web editor, you are basically using a "remote computer" (actually a Cloudflare Durable) to edit your files, just as if you cloned it on your local machine. When you're happy with changes, you "publish" it - which generates a commit for you. This way we can have developers and content creators happy, both sharing the same history.

> Site looks awesome and modern, good stuff! In another life I would be very excited about this platform.

Thank you! It's been a crazy one and a half year building this and we're now a team of 30 people all over Brazil. We thank you for the recognition!

Hi Orphea! Guilty as charged we kinda rushed this landing page for our TechCrunch announcement and haven't been able to come back to optimize it. I haven't heard of stuttering before now, but maybe something quirky is happening with your combination of browser/OS/CPU. If you could let us know which browser and OS you're on, we'd be very grateful! Thanks in advance!

BTW we're launching on Product Hunt today and we'd LOVE your support!

It's easy to code a loader to get data from any CMS! But we definitely intend to have proper Apps on deco.hub for every major CMS. At the end of the day, we want to satisfy your CMS needs without needing an external API. We're just getting started, would love your feedback on our discord!

I've been pushing for my team to try it out and a snarky engineer just pointed out they also break. Best of luck to the team at Deno! Hope service is recovered soon.