[HN Gopher] Launch HN: Creo (YC W24) - Build internal tools with...
___________________________________________________________________
Launch HN: Creo (YC W24) - Build internal tools with NextJS and AI
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)
Author : solias99
Score : 50 points
Date : 2024-04-02 15:43 UTC (7 hours ago)
| threatofrain wrote:
| I couldn't get enough information by reading your landing page or
| docs. Are you offering natural language translation to SQL?
| solias99 wrote:
| 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.
| mritchie712 wrote:
| (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.
| toddmorey wrote:
| 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.
| TheSaifurRahman wrote:
| 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
| dkindler wrote:
| Agreed with @toddmorey -- I think you could do a better job
| of highlighting the heavy-lifting that Creo does on your
| landing page
| aurareturn wrote:
| 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.
| spaceman_2020 wrote:
| 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.
| TheSaifurRahman wrote:
| _> 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.
| danielvinson wrote:
| You are basically charging money for things that
| frameworks like Django already have built-in, and have
| already had built-in for decades. There are so many good
| free options for this sort of thing. If a company already
| pays developers, there's absolutely no way they won't
| just build things themselves.
|
| 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?
| aidos wrote:
| 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?
| TheSaifurRahman wrote:
| 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.
| aidos wrote:
| So your environment has access to my db?
| rawoke083600 wrote:
| Agreed ! It looks really good. But not sure where or when I do
| the AI prompting ?
| solias99 wrote:
| 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!
| xcdzvyn wrote:
| Curious because your static landing page requires WebGL - what's
| your FE stack?
| solias99 wrote:
| 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?
| xcdzvyn wrote:
| 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 :)
| MaximumMadness wrote:
| 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
| solias99 wrote:
| 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.
| Closi wrote:
| 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.
| swyx wrote:
| 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
| solias99 wrote:
| @swyx I personally think it's not just about AI
| engineering, because step function improvements in
| foundational models means that everyone's AI stack is in
| trouble, not just ours.
|
| 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.)
| chipgap98 wrote:
| 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
| intelVISA wrote:
| How does this undifferentiated product gets funded by YC of all
| places - it's pretty DOA :/
| cashsterling wrote:
| You may eventually run into trademark issues with PTC Creo, which
| is a CAD program.
| https://trademarks.justia.com/851/62/creo-85162134.html
| solias99 wrote:
| Will look into this, thanks for mentioning!
| artathred wrote:
| 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.
| solias99 wrote:
| 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.
| codegladiator wrote:
| > 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 ?
| artathred wrote:
| 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.
| aerhardt wrote:
| I've tried Retool a few times and can't get into it. I
| simply don't feel comfortable in a web UI... I'm
| primarily a Django/React dev and I would love to see the
| Django Admin panel philosophy in the React world: quick
| to build, but editable code all the way down (and in the
| same repo as my core apps!).
|
| I totally see the appeal of this, I'm bookmarking it and
| I'm eager to give it a whirl.
| jimmyechan wrote:
| 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.
| aurareturn wrote:
| 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.
| solias99 wrote:
| 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.
| badrequest wrote:
| > 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
| aerhardt wrote:
| 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.
| artathred wrote:
| 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.
| slavetologic wrote:
| Anyone have any opinions on nextjs 14?
| willsmith72 wrote:
| 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"
| solias99 wrote:
| 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.
| flagged24 wrote:
| Being GPT compatible seems to be another major selling point.
| threatofrain wrote:
| 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.
| yunohn wrote:
| 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...
| solias99 wrote:
| 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).
| yunohn wrote:
| 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.
| artathred wrote:
| clerk.dev makes OAuth dead-simple, especially for nextjs
| apps (plug and play).
| sreejithr wrote:
| 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.
| ttul wrote:
| 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...
| tapoxi wrote:
| PTC uses it for their CAD software
| https://www.ptc.com/en/products/creo
| nsguy wrote:
| 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).
| DavidPP wrote:
| We currently using https://refine.dev/ with NextJS and Material
| UI for a CRUD type project. How would you compare yourself to
| Refine?
| solias99 wrote:
| 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.
| jddj wrote:
| 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.
| solias99 wrote:
| 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.
| real_kaipi wrote:
| would be great to have an actual demo site, and not just a video
| on youtube
| TheSaifurRahman wrote:
| You can clone our starter and play with it: npx creoctl@latest
| init
| codegladiator wrote:
| What is your next pivot ?
| buremba wrote:
| Congrats on the launch! How is the AI component better than using
| Copilot on VSCode?
| solias99 wrote:
| 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.
| atonse wrote:
| 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?
| solias99 wrote:
| 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.)
| IceDane wrote:
| My honest opinion is that I'm surprised by what YC is willing to
| back these days. Best of luck.
| swyx wrote:
| 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)
| ssijak wrote:
| 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.
| solias99 wrote:
| 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).
| dvt wrote:
| > 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).
| solias99 wrote:
| 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.
| motoxpro wrote:
| 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.
| solias99 wrote:
| Thanks.
|
| This is something we're actively working on fixing. That's
| where we're going with the project as a whole!
| dvt wrote:
| 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.
| solias99 wrote:
| 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.
| jondwillis wrote:
| Cursor.sh, Continue, and (probably? i dunno) Copilot do those
| things well.
| samuelstros wrote:
| 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...
| solias99 wrote:
| 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)
| aerhardt wrote:
| Why are RSC more LLM friendly that traditional React?
| solias99 wrote:
| 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.
| ergocoder wrote:
| 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.
| threeseed wrote:
| 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.
| adityavinodh wrote:
| 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.
| cushychicken wrote:
| FYI Creo is already the name of a pretty popular mechanical CAD
| tool.
___________________________________________________________________
(page generated 2024-04-02 23:00 UTC)