Hey HN, Rohan and Saif here from Creo (https://trycreo.com/). Creo lets you make internal tools with NextJS. We’re code-first because we think engineers prefer being in their IDE (especially today, with all the advancements in dev-tools) when building out internal tooling for their company.
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)
Congrats on the launch.
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.
First half of the video I was like, I am watching a random next JS youtube video. Then when the AI stuff came in I was like ahhh they just have a massive positioning/messaging problem. Not that I would use it, but positioning yourself against boilerplate, auth, optioned starters, etc. is really really rough.
Thanks.
This is something we're actively working on fixing. That's where we're going with the project as a whole!
Makes sense! I would say flip your video and put the AI stuff upfront. At least then people can see what you have/where you're going.
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 :) )
Great feedback, thanks!
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.
My honest opinion is that I'm surprised by what YC is willing to back these days. Best of luck.
I keep thinking this. This comment feels like the elephant in the room people don't want to say because of getting downvoted etc.
most founders pivot during YC. if you're YC you're backing the founder not really the idea (altho ofc a little bit the idea)
What's the value to users if you are NextJS based?
- 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...
I'm guessing NextJS because internal tools need to make requests inside the DMZ without authorization.
(The huge mental disconnect between people who only ever make websites and people who make business tools is amazingly huge.)
Mainly their implementation of React Server Components, which is a far simpler set of APIs to work with compared to traditional React. (Also very LLM friendly)
Why are RSC more LLM friendly that traditional React?
1. Very clean, easy to understand APIs.
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.
I agree with these points. Nextjs, from my understanding, is primarily aimed at websites. I also worry about lock-in.
Just a bit of feedback. I think you’re closing in on a differentiated offering from low-code, but I read the site & docs intro and I still can’t tell what you provide over Next on Vercel with an auth provider like Auth0 or Clerk.
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.
Co-founder of Creo here. We realized that providing common features like auth, components, group permissions, and white-labeled deployment adds significant value, especially for those seeking an opinionated solution. While these tasks are relatively straightforward to achieve, they can be time-consuming due to the numerous options available.
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
I want to be convinced because building internal tooling is hard.
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.
Yeah, the pricing seems completely wrong to me. No developer I know will pay $30/m plus usage for auth and permissions.
They know building it out isn’t so hard that it justifies paying 30 bucks every month forever.
> we are still the ones building most of the tool.
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.
You have an uphill battle against mature free options. Charging like you’re Retool right now guarantees that no one will even bother with you.
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.
Well, if it costs $10,000 all-in to pay a developer for 1 month, and Creo costs $30/month, then it would take 27 years to break even on having a developer spend the extra month building it from scratch.
I had a flick through the docs but I don’t quite get how deployment / connection to dbs etc works.
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?
Not sure if you watched the YT video.
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.
So your environment has access to my db?
Agreed with @toddmorey -- I think you could do a better job of highlighting the heavy-lifting that Creo does on your landing page
Agreed ! It looks really good. But not sure where or when I do the AI prompting ?
Once you install our starter via this:
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!
You may eventually run into trademark issues with PTC Creo, which is a CAD program. https://trademarks.justia.com/851/62/creo-85162134.html
I was going to point this out as well. It’s wise to avoid conflict before gaining too much traction.
Disclaimer: I worked for PTC.
Will look into this, thanks for mentioning!
This looks very similar to an opinionated boilerplate, rather than a low-code competitor. IMHO that’s a tough commoditized space, and your value add is not clear to me…
We think there's value in an opinionated boilerplate!
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).
I agree. I'm a single dev working on building a product. I don't mind opinionated platforms. Because I want to putting in the least possible amount of effort. I'm sure there are probably a lot of users like me.
I’ve setup OAuth before and it can be painful. But it’s become more straightforward these days, with existing boilerplates.
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.
clerk.dev makes OAuth dead-simple, especially for nextjs apps (plug and play).
I think there's a trap that hits founders: "What do you have to do before you build your unique idea?"
Well you need to setup boilerplate, buy a CRM, buy an email marketing tool, etc. and like 30% of companies think "oh this kind of sucks" and make one of those steps their company.
Nothing against the project but certainly one of those.
In particular I think it overestimates then pain they solve and underestimates both modern frameworks eg. T3 stack, and in particular how difficult getting something through enterprise procurement.
I can't imagine it being easier to get this bought than to do that stuff yourself, particularly when it makes you look bad as a dev to need help with the basics.
Thanks for mentioning this, but it's definitely not what we're trying to achieve.
We may have underplayed a little, only because we have existing users already finding value with our current setup.
The goal is more like v0.dev, where with a prompt, you can generate your entire internal tool. We think we're not too far away from this (as shown in the YouTube demo).
That's a better description and a better goal
I think this is a cool idea. I have personally been in the position where you have built a product, and now you suddenly need to start thinking about internal tools to view and manage your product. Building them are crucial, but it's also something where you don't want to spend too much time. While this seems great, my only suggestion is if this could be a little bit more extensible. This appears to restrict you to NextJS. It would be nice if you could give us framework agnostic blocks and APIs that we can use with any technology. I wouldn't mind paying for it as long as it is reasonable.
Give streamlit a shot. Since I started using it I’ve been churning out internal tools at the pace of one every few days.
Can you help me understand the value prop of what you're offering? The positioning makes me think this is a just shadcn component product + Next on Vercel, neither of which require paying for an additional platform
The core value prop is 2 things: 1. Not having to deal with authentication, team permissions, organization management and a good UI/UX. We do this by embedding the tools you create into our parent web app. 2. An AI offering (as shown in the first video) that allows you to quickly scaffold out your tool with just a prompt when developing locally. It knows about our components and auto applies code changes, so the feedback loop is faster.
I don't think number 1 is a differentiator anymore (there are so many boilerplate bootstrap templates that include OAuth).
2 is certainly a differentiator, but not mentioned anywhere in your post.
2 is a very doubtful differentiator, any decent ai engineer can do what they showed. they’ll have to deepen their ai stack a lot more to not be clonable there
But you're using shadcn components, which are open source. Everyone has access to those components. I don't understand how you will be differentiated
How does this undifferentiated product gets funded by YC of all places - it's pretty DOA :/
To me, this is a cute toy, but I highly doubt the AI can generate anything actually useful. Plus, I already have a code editor open, so context-switching to the browser to do "coding" feels a bit non-ergonomic.
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.
I'll chime in with my personal experience: I spend about 50-60% of my time in GPT-4 just pasting code, prompting for what I want and then pasting it back into my code editor.
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.
Cursor.sh, Continue, and (probably? i dunno) Copilot do those things well.
There has been a ‘get rich quick’ thing going on with devs selling ‘saas starters’, so, while a few years ago that was interesting niche, now there are 1000s of them, open source and closed source. Most of them include all components to build both the saas functionality (which can be the internal tool) and the outside (landing, sales pages, docs and subscription payments). They all include auth and most are nextjs. With those tools you can whip up stuff in no time.
Yeah I made a project with Supabase for the backend, Vercel for the frontend (literally all you do it git push and it handles deployments), and then Nuxt.js for the frontend.
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.
I don’t think the ‘sure’ is sure. Take off Twitter/fb style yes, but take off most businessee do, you would be fine. Even with that.
I couldn't get enough information by reading your landing page or docs. Are you offering natural language translation to SQL?
(note: I'm a founder at Definite)
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.
No, not natural language translation to SQL.
We 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.
I'm genuinely curious how this YC is funded?
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.
I implore you to try the product.
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).
I can do that manually with existing tools in half an hour. Endpoints change very rarely, once you setup your "view" of that endpoint you are mostly done for a long time, with some smaller changes over time.
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.
This is the exact thing I've personally tried several times and it doesn't work well. But it works with a prompt in our app right now.
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.
> 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."
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).
Just like Retool (or any other platform), you're expected to bring your own endpoint (but you're also free to write it in our app if you want).
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.
To be truly honest - this feels like all of the lockin and downsides of a framework, without the upsides.
Putting this through a security review even if it was free greatly outweighs the upside. It also reflects badly on me as a developer if I was to propose this?
As everyone mentioned, there are tons of OSS alternatives which are well established. One of which is tooljet: https://github.com/ToolJet/ToolJet
I don't appreciate the boosting of alternatives when someone is showing on HN. One should be encouraging and give feedback on the product itself.
"boosting of alternatives"
It's called benchmarking and it's part of presenting a tool. You should be able to explain what your tool has to offer over the alternatives.
This is a horrible tactic - allow them to promote their product. Why did you mention Tooljet (a particularly bad alternative) when they already mentioned it?
When I see an idea like this funded, I always feel they raised based on founder's strength.
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.
Just to save everyone time: Rohan has built apps where "1 million people have used the products".
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.
FAANG is not even that special unless you are the one who created a new product line or early employee.
Building a product with 1m users is much much more impressive, especially with no funding and team.
We currently using https://refine.dev/ with NextJS and Material UI for a CRUD type project. How would you compare yourself to Refine?
Thanks for bringing up Refine, we are closest to them in terms of product.
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.
FYI Creo is already the name of a pretty popular mechanical CAD tool.
And Apple is the name of a pretty popular fruit.
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).
I'm not fully understanding your product here. If I have a NextJS app, is this like Copilot that would help write some of the component code? If so, how is it better?
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?
All you do is write a single page in the tools folder and deploy.
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.)
would be great to have an actual demo site, and not just a video on youtube
You can clone our starter and play with it: npx creoctl@latest init
Creo was a legendary printing technology company that got its start making optical data tape in the early 1980s. I'm sure the trademark is fine to use for a software company, but you might want to ask Kodak to make sure.
https://en.wikipedia.org/wiki/Creo_(company) https://www.theglobeandmail.com/report-on-business/kodak-buy...
PTC uses it for their CAD software https://www.ptc.com/en/products/creo
I worked there ;) legendary indeed. EDIT: Creo was also a software company by the way so the trademark was definitely used on some software (mostly related to the printing industry but anyways).
Great launch but curious, why would I use this over Retool? I’m an engineer and the thing I love about Retool is the low-code UI components (saves time sourcing those same libs) + everything done on Retool so I don’t need to dedicate local disk space to my non-important internal app.
Retool is a great solution if you like low-code, so I think it mostly depends on what you like.
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.
> 2. We have an AI offering that allows you to create your tool with just a prompt and iterate on it
IIRC Retool also offers this functionality: https://retool.com/products/ai
> I had trouble with low-code builders when building more complex apps
Can you elaborate on this ? Which trouble you came across while using which low-code builder to build what kind of complex app ?
I couldn’t imagine building our internal tool with retool.
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.
Sure, bear with me for this might be a long answer. I'll start with some of my own use cases I tried and then expand into where I think this space is going.
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.
I second this, the whole point of Retool is that you can build complex apps that you couldn’t with pure no code solutions (i.e Airtable/Notion).
Retool replaced a pain point (devs don’t want to code internal apps) that is now being brought back with a solution like this.
Co-founder of Dropbase here. We're a better fit for you given your comments about Django and being in the same repo.
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.
Local disk space for internal apps is a concern for you? I’ve never thought to measure the amount of space that a Django Admin app or a custom-built React admin app might take in my hard drive… At any rate I know I prefer having every environment locally and not only in the cloud, and I suspect I’m not the only one.
it’s not only about the space, it’s about the management. When you’re an enterprise managing hundreds of internal apps, it’s way easier to just go to retool.com and find everything vs it all being stored local.
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.
Anyone have any opinions on nextjs 14?
Personally I think they are on the right track, which is why we're over-invested in them.
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.
The needs of internal apps & dashboards are so spiritually different than the needs of consumer-facing software, and Next has been all about the consumer-facing side for the last few years. I think betting on Next is correctly simply because they're massive, but in some ways it's a bet despite everything that Next has been about for the last few years.
Being GPT compatible seems to be another major selling point.
these days i'd choose remix instead. next 14 is fine, but i feel more productive with remix and when i don't know how to do something, remix usually has a way better "principle of least surprise"
Congrats on the launch! How is the AI component better than using Copilot on VSCode?
Mainly it's that the AI knows about our component library, so you don't have to inject context all the time.
And we try to be meticulous about our components' API design, that's where we think most of the value accrues.
What is your next pivot ?
Curious because your static landing page requires WebGL - what's your FE stack?
We are using WebGL only to draw the globe, but on smaller screens we actually replace it with a static image. Are you seeing performance issues on a laptop?
Not at all, I just have WebGL disabled by default.
I wasn't sure if the entire page was being rendered through it, that's all :)
[flagged]
It is a difficult space for sure.
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.