Retool Enterprise Features vs Real Needs of Small Engineering Teams

[Darren]

Ah we're talking about different things. Most traditional API endpoints are still scoped to Enterprise - you can see the exceptions here - but our official MCP server is a distinct offering that makes most of its distinct tools available at all plan levels. It's currently in open beta and only available on Cloud, but will ship in the next stable release for on-prem customers.

When that happens, there is a good chance we'll bring API access into alignment. Does that clarify my original statement?

[appbuildernyc]

Everything is kind of complicated because of these strict feature restrictions.

Experienced users already have standards and intuition built during many years of working with software and infrastructure. Simple example — every time I want to save, import, or export something, I naturally look for “File” in the top-left corner. That’s a behavior learned from years of experience. If someone suddenly moves it to the bottom-right corner, I may never even think to look there.

For me, API access, Git integration, Sentry integration, MCP support — these are already very basic things required to build something stable and reliable. Not “enterprise luxury” features.

At this point I already learned too much about Retool internally just to keep my environment stable enough:

• how the Postgres structure works
• how page trees are stored
• lookupPageByUuid
• what Redis is used for
• what can be cached on the web server side
• blue/green deployments
• backups and restore procedures
• custom Git workflows
• splitting huge pages into multiple pages to improve loading times

Maybe that sounds impressive, but honestly, I was never supposed to deep dive into Retool internals that much just to operate it comfortably in production.

And this is not even about me needing help anymore. I already built my own workarounds. I cloned large parts of the Retool experience with Claude already. I made my own automation instead of MCP. It opens edit mode, makes changes, compares structures — everything works. I’ll survive.

That’s not the reason I opened this topic.

I just wanted to say it feels bad (actually s*cks) when very basic operational capabilities are treated as enterprise-only features, while small teams are not even allowed to upgrade into those plans sometimes.

I simply wanted to understand if our philosophy matches. Because historically, almost every great technology ecosystem was built by communities sharing the same philosophy around openness, flexibility, and empowering builders.

[appbuildernyc]

Retool 16.56s load time - page itself takes 8-9 seconds to load fully

Custom React-based platform cloned by Claude, same 711 records, 411ms load time

And I just made a tool after investigating how you structure data, etc Claude is opening a browser, checking everything, and then magic happens and yeah… MCP is not released for self-hosted retool yet…

[appbuildernyc]

Just to clarify one important point: If you could provide me all the necessary tools and basic operational features, I would never even think about building something custom.

I’m a technical person with many years of serious experience across infrastructure, software, systems, and architecture. If I really need to, I can build a Retool-like tool myself, clone Appsmith, modify it, or create something custom. That’s not the problem.

The problem is: this is not my business.

I make money in a different industry. I’m using Retool to build internal tools for our own operations, not to become a platform vendor or spend my time optimizing internal tool frameworks.

I don’t want to care about Retool versus React, server-side optimization, performance analysis, page rendering details, or rebuilding features that should already exist. If the right tools were available to small teams, I would never even consider building anything custom.

I’m busy with more important and frankly more interesting business problems.

For me, the page does not need to be perfect or insanely fast. It just needs to be decent, stable, observable, maintainable, and not something I feel ashamed to use in production.

That’s the whole point.

[Shaun_Smith]

I can understand your frustration because features like Git integration, monitoring, observability, and error tracking are no longer “enterprise luxuries”; they’re essential for maintaining stable production systems, even for small engineering teams. Many growing start ups hit this exact problem where the platform scales technically, but operational tooling becomes restricted behind expensive enterprise tiers.

[appbuildernyc]

They’re not even allowing small companies to upgrade to the Enterprise subscription. There is a wall, and you keep hitting your head against it, but there’s nothing behind that wall. They already know this problem exists, but things are still designed that way…

[Darren]

Thanks for all the feedback, everybody! Getting this perspective is genuinely valuable and helps to shape the way we think about pricing and packaging. I have more to say about how that relates to our mission/philosophy and will share shortly!

@appbuildernyc

They’re not even allowing small companies to upgrade to the Enterprise subscription.

Is this anecdotal, @appbuildernyc? Nobody should be turned away and I can personally connect you (or any other interested parties) with a sales rep.

[mawdo81]

I find it a hilarious (as if you didn't laugh you'd cry) irony that a company built to enable "ordinary" users to leverage 3rd Party APIs so heavily gate keeps its own that would make it easier to build more with Retool, and hence be stickier

[appbuildernyc]

Good luck.

We clearly can’t communicate.

I really dislike speaking with people who have zero desire to understand the actual concern. You’re doing your job, checkmark done, another 50 posts handled today.

I’m bringing up something people are genuinely annoyed about regarding your product, and first I get invited to office hours, then my feedback gets called “anecdotal.” What can I even say at that point?

Good luck.

[appbuildernyc]

Just to clarify — it’s been 17 days since I opened this topic, and many people found it interesting enough to share their own opinions and experiences.

During this entire period, I didn’t get anything meaningful back from Retool. No proper response, no follow-up, no sales call, no attempt to understand whether they could actually help me or keep me as a customer.

Just nothing.

And that means something to me. At this point, I don’t see a reason to keep wasting my time anymore.

[Darren]

Before I get into it - @appbuildernyc, "anecdotal" was the wrong word. I intended it to be a genuine question - are you speaking to your personal experience with Sales, because I'd like to fix that if so - but should have been more clear. Apologies for that.

Now I want to share the philosophy piece I promised earlier, as well as a frank take on everything that's been shared.

To start, this thread has been surfaced to leadership within Product. I'm flagging that because "we'll pass it along" can feel dismissive, and I want everybody who engaged here to know that their feedback actually landed somewhere it can be acted on. I can't commit to specific packaging changes right now, but the conversation is happening at the right level.

In terms of substance, @appbuildernyc, @Shaun_Smith, and @mawdo81 have all made very real points. Source control, error tracking, and performance monitoring have historically been enterprise differentiators but are increasingly becoming baseline expectations for anyone running production software. I think that's a valid read of where the industry is.

In terms of philosophy, Retool's internal mission is to "bring good software to everyone." It's fair to ask - as this thread effectively does - whether the current shape of the product fully lives up to that and I don't want to ignore that tension. @mikeS is right that moats matter for a business to exist at all, but the question at hand is understanding what specific functionalities make up the moat. That's something we are genuinely debating internally and threads like this are useful input.