Launch HN: Creo (YC W24) – Build internal tools with NextJS and AI
Here’s a demo of writing code and then deploying your tools: https://www.youtube.com/watch?v=GDTk1SmtpXw And here’s one on how to get started with the CLI: https://www.youtube.com/watch?v=JyyyRv2TJy0.
A lot of internal tool builders (eg: Retool and Tooljet) are low-code, meaning you’re given a WYSIWYG drag-and-drop UI where you can drag components onto a canvas, and then wire them up to a data source or endpoint using a form/code-block. This has the advantage of being accessible to non-programmers, who are often the people needing and using the tools. What we’ve repeatedly seen, however, is that while these solutions begin with a PM (or similar) creating the initial tool, they soon bring in an engineer to e.g. wire it up to a data source or an endpoint. But engineers dislike dealing with this drag-and-drop stuff—it would be so much easier for them just to do it in code. So these products become stuck somewhere between code and no-code.
We experienced many such problems building internal tools at companies we’ve worked at in the past. We tried the aforementioned low-code builders and found the tools hard to maintain as they became more complex. We wanted to write the JavaScript we’re comfortable with, but it was always hard picking the libraries/dependencies to get started. We never found a good, opinionated set of abstractions to build internal tools quickly.
Our solution is simple: you use our CLI to clone our NextJS14-based starter and run it on port 8891, where you write the React/JS you’re comfortable with. All you have to do is worry about the app/tools folder, where you can create new directories for the tools you need to create. Everything else is configuration files. Once you push your project to a GitHub repo, you can connect that repo to our platform on our deployments page. We also have a component library (built on top of Shadcn), that will save you time, especially with things like data tables, forms and charts.
The tools will then show up on your dashboard and be usable in about 1-2 minutes. The rest of the platform has all the other features you will need, such as being able to add team members to your organization, configuring permissions, keyboard shortcuts, authentication and more.
The real value, in our opinion, is that you will never have to do authentication, manage team permissions, and worry about components. Because it’s code-first, it also becomes dead easy to coordinate with your team via source control, and take advantage of tools like GitHub Copilot to write repetitive code fast. Our current pricing is free to get started as an individual, and subscription based pricing for teams (Currently $30/mo up to 5 users, later seat-based subscriptions).
You can try Creo today by heading to https://trycreo.com/, or get started without signing up by looking at our docs (https://docs.trycreo.com).
We’d love to hear your feedback.
Edit: We also have an AI offering that is live today. You can grab an API key from our web app, add it to your .env locally and ask it to generate the tool you have in mind! (The YouTube video shows you how you can do this)
108 comments
[ 0.41 ms ] story [ 195 ms ] threadWe allow you to build internal tools, like Retool. This includes admin dashboards and CRUD apps. You can do it either through code or asking AI.
If you're looking for natural language -> SQL, you might like https://www.definite.app/. We help you query your data with natural language in a safe, repeatable way thru a semantic layer. It's all SQL under the hood and we even spin up a duckdb data warehouse for you which gives you great performance without a ridiculous cloud warehouse bill.
I think you need to make that really clear as now you are building more a case to build internal tools with React than specifically with Creo.
Additionally, we do have an AI offering as well, which has the information about the components, check out this video here: https://www.youtube.com/watch?v=GDTk1SmtpXw
But I sense that your solution should actually be an open source repo starter and not a $30/month plan based on number of users. That seems absurd because we are still the ones building most of the tool.
auth - why do I want to use your auth over the many tried and tested auth solutions for Next.js? Where are you hosting the user data? Or are we hosting the auth data ourselves?
Components - there is a hundred dashboard component UI libraries. Some of them are very extensive and good. Why do I have to pay for this?
Group permissions - this seems fairly straight forward to implement. Some auth solutions also have this built in.
White label deployment - what does this even mean? Next.js deployment is easy enough on Vercel.
In terms of AI offering, it’s not much different than asking ChatGPT and I already pay them $20/month.
I hope it doesn’t come off mean because I do want something that is more powerful than retool but easier than coding from the start. I just don’t see the value at all in this.
They know building it out isn’t so hard that it justifies paying 30 bucks every month forever.
You will always have to build the piece of software that's specific to your needs. A framework can only make it simpler. Today, we are writing code; tomorrow, you'll need to prompt/draw/imagine in your head (hopefully) to get something built.
> auth - why do I want to use your auth over the many tried and tested auth solutions for Next.js? Where are you hosting the user data? Or are we hosting the auth data ourselves?
To set up auth, you'll need to set up keys, webhooks, and SSO for the providers. Just to mention, the auth is not part of the boilerplate; the auth is applied when your repo is deployed, as we embed your repo on our platform.
We are also using Supabase internally, so that's where the user data is hosted. You can of course build your solution with one of the many solutions out there. But we wanted to keep it simple keeping in mind all the use cases of a regular internal tool. For example, it may change to something else as we offer SAML, etc.
> Components - there is a hundred dashboard component UI libraries. Some of them are very extensive and good. Why do I have to pay for this?
You are right, there are many options, and most of the time, going ahead with any of the maintained ones works out with no issues. We want to be one of those many. Right now, we are using shadcn/ui, but later, we will develop/extend components that are frequently used in internal tools with a reduced number of properties. Our UI library will be open-sourced; it's not something you will have to pay for, and you can use it with any of your projects, as it's an npm package.
> Group permissions - this seems fairly straight forward to implement. Some auth solutions also have this built in.
Yes, it's straightforward, but time-consuming to build. I have yet to see a built-in solution where you can configure things like which team/group should have access to which tools. Most built-in solutions stop at assigning groups/roles, and it's because tools (or some generic entity) may not be relevant to their users (unless it's a solution for internal tools).
> In terms of AI offering, it’s not much different than asking ChatGPT and I already pay them $20/month.
We want to be on top of the game in terms of the AI when it comes to any knowledge that Creo should have, like its components, how to glue them together, error handling, and being fast with feedback loops (not taking a huge prompt and minutes to build the entire app like many other solutions). ChatGPT could be really good, but it will be spitting out unopinionated code, and to get it to produce code in a certain way, you'll need to prompt it heavily. Think of mentioning "Use shadcn's card in light theme" every time you want a card component. The value here is in the context being provided by default.
All of your selling points are things that business people think are difficult but any developer worth their salt will tell you is no problem.
Edit: to add a bit more info here... think of it this way: I am a frontend developer. I can build a specific dashboard in about 2 months, using things I am already familiar with and will look great. Instead, I can use your product and reduce the amount of time it will take to 1 month, but lock us into paying a monthly subscription for the rest of time. How could I possibly convince somebody to buy that?
Quite honestly, I don't see much value in the non-AI part. I can replace all of that with a free Supabase instance and a free Next.js repo-starter.
You should make an open source version for free without the AI. And just charge for the AI.
My experience this these tools is that they generally end up having a convoluted system in order to let you use the tool while connecting to your own dbs without handing over access or you hand over access.
Could you explain how it works in your case?
But here is how it works.
1. You clone our starter, which is a Next.js boilerplate with our UI package (uses shadcn): `npx creoctl@latest init`
2. You run npm run dev, and this starts the local server. You'll get a chat prompt on the screen where you can ask the AI to make the changes, and it'll write the changes to the disk, or you can write code by yourself in your IDE.
3. You push it to GitHub.
4. You create a new organization on https://app.trycreo.com and connect your repository.
5. You access your tools from the dashboard.
You'll need to connect to your own database, we currently do not offer managed database instances.
npx creoctl@latest init
cd into the project, download the dependencies, and npm run dev.
On port 8891, you can open any of the tools (or create a new one) and a chat box appears on the right. There you can ask for what you want!
I wasn't sure if the entire page was being rendered through it, that's all :)
2 is certainly a differentiator, but not mentioned anywhere in your post.
For us, an underrated part of what is valuable is the components and their API design. Being able to have a <DataTable /> with just the right props for the right use cases, so that a foundational model doesn't go and build it from scratch is useful. The reason is mainly because now you save money on tokens, and save time because faster inference (since abstractions are already in place).
tl;dr give AI the right tools > trying to compete at foundational layer. (We are building those tools.)
Disclaimer: I worked for PTC.
For us it's 2 reasons: 1. I had trouble with low-code builders when building more complex apps, so I had to fall back to code. In that sense, we aim to be a thin wrapper around code (by making sure you don't write things like authentication, RBAC etc.)
2. We have an AI offering that allows you to create your tool with just a prompt, and iterate on it. It works more often than not because we're heavily opinionated on what components to use and how our app should be setup. The feedback loop is also faster than low-code because you're just iterating with prompts, so there's lesser cognitive effort.
Can you elaborate on this ? Which trouble you came across while using which low-code builder to build what kind of complex app ?
Retool replaced a pain point (devs don’t want to code internal apps) that is now being brought back with a solution like this.
I totally see the appeal of this, I’m bookmarking it and I’m eager to give it a whirl.
We are an internal tools builder that works with your existing Python codebase, in the same repo as your core app. You can call/use your exiting Django models from Dropbase UI components, and build fullstack internal tools with just Python.
For example, complicated business logic form validation that requires calls to the database or external api.
We tried it. Retool ended being much more complicated and restrictive than our Next.js internal tool app. We went back.
I even remember reading on the official retool documentation website saying you should probably not use it if your internal tool is fairly complex. It was honest.
With Retool, I tried building a form where if I change one input, the other input needs to conditionally change. I struggled a little with figuring this out, more than I should have. I also find it unwieldy to do any complex state management with a low-code builder (as in the case above), so it was a no-no for me.
At the same time, I understand that this feels like "writing code all over again".
The reason we don't believe so is because there's a hidden cost (cognitive effort) associated with picking the right component library, the right framework, etc.
Eventually, you won't be writing too much code either way for CRUD because of AI.
Let's say you want to edit some of the styling. Instead of writing some TailwindCSS, you will just ask our AI to say "move this graph to the right of the table" and it will just do it. We're opinionated to the point of having our own CSS rule engine, to make sure that the padding is always the same when adding new elements on to the screen, so the goal is for you to not write code as far as possible.
Have a look at https://v0.dev, it paints a good picture of what we're trying to do with this.
IIRC Retool also offers this functionality: https://retool.com/products/ai
It’s an internal app, nobody wants to dedicate more $$ and hours than they need to managing/building it.
Again, whole reason why Retool even took off in the first place.
Generally in our experiments, GPT-4/Claude Opus is able to generate Next-flavored React Server Components (RSC) a lot easier than anything else, because their APIs are simple.
But beyond just boilerplate, once you deploy your tools on our platform, we embed them in our parent web app which has the things you wouldn't want to bother writing (authentication, RBAC etc).
Also, we have AI that allows you to prompt for the tool you want when developing locally. It's actually live today, and we also show it in one of the videos.
The bigger goal is to have AI scaffold out your tool with our opinionated stack (the feedback loop for that is much quicker than asking GPT to create an entire web app).
The AI prompted scaffold sounds pretty useful, though I’m not convinced it’ll be a USP moat.
Good luck nonetheless! Internal tooling and automation is an incredibly large market that has no clear winner yet.
https://en.wikipedia.org/wiki/Creo_(company) https://www.theglobeandmail.com/report-on-business/kodak-buy...
Unlike Refine, we are highly opinionated on what you should be using, including component libraries, NextJS etc.
We think there's value in constricting the scope of what you can use because with our AI (which is live today), you can prompt for the tool you have in mind and it's going to give you something that looks good out of the box, which cuts down feedback time by a good chunk.
While I agree that low code is often a trap, I imagine this is a very difficult space. Once you go away from low code and towards low effort, you're then in the realms of supabase and pocketbase, which have that particular niche nailed pretty well without marrying to a particular front end framework.
I personally now wouldn't stray from pocketbase for internal apps because an alternative offered hosting and some UI components (when I have a whole internet full of hosting and UI components -- see: tough space, selecting for people who do have some coding ability). But I can see how a really well integrated solution could be valuable to others who happen to click with its flavour and degree of opinionatedness.
We think the value is not just in one thing or the other, but being very focused on the whole: component library, framework, etc. and not giving options.
The reason is because it ties together nicely when you prompt our AI to generate the tool you want.
When you say "Give me a table on data X and a bar chart that is groups field X on the same data", there is no cognitive effort expended in thinking about which component library to use, getting AI to know about said component library, and writing code straight into your project.
And we try to be meticulous about our components' API design, that's where we think most of the value accrues.
Then when you say you provide Auth etc, does this mean we have to fully commit to use your stack for auth etc, or can we put this in an app that has existing auth with, say, Auth.js or similar?
We embed those tools in our parent web app, which has authentication, team permissions etc. So you will never interface with the code that does that.
You just have to focus on your business logic.
In terms of the AI copilot, the main value prop is knowing about our components, and using them to stitch together something fast. (Instead of the AI writing the component from scratch.)
This is targeting developers who are already using tried and tested solutions for this kind of problems, which are all open sourced or, if not, well established.
There are dozens of choices for auth, component libraries and any other lego piece you need. And it is very easy to piece them together and have full control.
I would almost never trade small perceived gain in speed of pushing first version of some internal tool, for much much lower flexibility, cost and lockin over life of the project.
The value is in being able to prompt AI something like "Here's my data that comes from endpoint X. Give me a table that shows this data that is also searchable."
I personally find that valuable (along with not having to think about which auth vendor and component library to use).
This is a billion dollar idea even if at like a 70%+ success rate. And as a data engineer, I assure you the success rate is not there. There are so many edge cases, so many caveats, so many headaches; an AI generated solution will only work in the perfect API scenario (which never happens in the real world).
The value will be in closing that feedback loop:
1. Here's the shape of the data coming in from endpoint /api/xyz. Currently, generating an endpoint with AI with this much nuance is very low in terms of success rate (and I think is what you're talking about).
2. However, once you know the endpoint and what the data looks like, our tool becomes valuable because you can just specify in natural language, which component you want to use, and how it has to be laid out on the page. Several people will prefer natural language over dragging and dropping UI elements on a screen. And the success rate is far higher for something like this.
Also if I wanted to go AI route, I can ask Cloude Opus or GPT4 : "Here is an endpoint that returns this type of data <paste data type here>, make me a React component that fetches this data and presents it in searchable table using shadcn"
It will get me 80-90% there, it would need just a little manual tweaking to conform to the current project code standards.
Some reasons listed below:
1. Gpt hallucinates shadcn's big data table implementation more often than not. Also, you don't have props for everything by default (page size, filtering, sticky columns etc)
2. We have certain rules we ask our AI to stick to, such as always putting a table in a card and consistent padding. So there's lesser cognitive effort in you thinking about how to style your tools.
3. Current LLMs are shaky with next14 right now, especially on where to use server and client components.
This is something we're actively working on fixing. That's where we're going with the project as a whole!
more of a "Use AI to generate internal tools" (the language, auth, UI, etc. could be anything. even though react is a great start.)
In time you could generate the stuff in any language people want "use the language you love instead of constricting no-code or inflexible boilerplate starters"
The boilerplate is less than valuable because you're competing with already established open source communities that "will be around long after you go out of business or pivot" (quote because of sentiment but not because I think you're going out of business :) )
We mostly shrunk away from pitching the AI because we thought people will find immediate value in the starter and be able to use it (like our existing users/customers), but in hindsight that was a mistake, especially considering the AI is already decently valuable.
I'd also like to see what the failure state looks like ("no, AI, not like that") because that's the main pain point when using tools like Copilot. The amount of time spent tweaking the AI prompt (or multi-shot re-prompting) ends up being comparable to just writing the thing yourself.
Like @IceDane and @ssijak, I'm also a bit shocked at what YC is funding these days.
If this is my workflow most of the time, then surely this can be more streamlined. The way to streamline it would be:
1. Can I tell GPT-4 about my components (and always be up to date)
2. Can I ask GPT-4 to write to the file directly
3. If the output has an error, can I ask GPT to look at the compile time error and auto fix it?
The 3 things I mentioned above is something I do every single day. We're just looking to make it easier.
- internal tools rarely (never?) need SEO
- the complexity of NextJS rings alarm bells as infra product. A look at your docs confirms my suspicion https://docs.trycreo.com/core-concepts/server-and-client-com...
2. Easy to make API calls.
3. Easy to reason about server/client component boundaries
Makes it easy for an LLM to write code without all the cruft/boilerplate.
(The huge mental disconnect between people who only ever make websites and people who make business tools is amazingly huge.)
It seems this is the case. One of the founders seemed to build a few successful apps in the past.
The idea is okayish. It is useful for sure but the space is crowded with tons of alternatives.
Otherwise nothing that special. Just two young, competent engineers. No FAANG or second time founder.
I suspect the real reason is that they had launched, had decent amount of traction and had a point of difference.
Building a product with 1m users is much much more impressive, especially with no funding and team.
Products and companies in different industries can share a name without trademark infringement. Apple only had to buy Apple Music (a la The Beetles) when they got into the music business (iPod).
It was pretty simple for someone who had no frontend experience. I will say that I'm sure if the app took off it would have scaling issues, but for the few users it had this worked fine.