Key takeaways
- With Retool, a team without developers still needs someone to act as the builder, either hired or trained, and that person can become the bottleneck for change.
- A good alternative removes the builder role: the tool is built on the systems you already run and code does the calculations.
- Whatever tool you choose, decide who owns the rules, who reviews the first results and who is told if a connection stops working.
- Before building, check the Fortnox integration licence, scopes and rate limit, the HubSpot access type and a customer key both systems share.
- Retool remains the right choice when engineers want to build, own and change the code themselves.
Why Retool stalls in a team without developers
Retool expects someone on the team to write code. Its own material says it was built developer-first: you write JavaScript and SQL, connect directly to databases and APIs, and manage apps in Git.
For a finance, sales or operations team without developers, that leaves two options. Either someone learns enough SQL and JavaScript to build and change the app, or the company hires a consultant to do it. In both cases one person typically ends up holding the queries, the connections and the knowledge of how the app works, and every change request waits for that person.
Business rules also tend to move into the app. The rules that decide what counts as an open invoice or an active deal often end up in the app's queries, which can be hard for non-developers to read or check. When the builder moves on, the team can be left with an app it can use but not change.
If that bottleneck sounds familiar, reviewing one bounded process can show whether the builder role is really needed.
Talk to us
Review one bounded process with Ronja.
Talk to usWhat a good Retool alternative looks like without developers
A good Retool alternative for a team with no developers removes the builder role instead of making it easier to learn. The tool should be built for you on the systems you already run, keep business logic where the people who own it can check it, and stay running without a named developer behind it.
In practice, that gives four tests to apply to any option on your shortlist.
Ronja is built around that model: it connects to the systems a company already uses, such as ERP, CRM and finance systems, and builds and runs software for the work that happens between them. With an agent-built approach, the team's effort can go into describing the process and checking the result rather than designing screens and writing queries.
Applying these four tests to one bounded process of your own is a practical way to compare options.
- It connects to your ERP, CRM and finance systems and leaves them in place.
- Matching and totals are calculated by code, not estimated by a language model.
- Business definitions are shared, not copied into every app.
- Access, changes and monitoring come with the platform.
Talk to us
Review one bounded process with Ronja.
Talk to usRetool compared with an agent-built tool on Ronja
| Dimension | Retool | Agent-built on Ronja |
|---|---|---|
| Who builds and maintains it | A builder who writes JavaScript and SQL and manages apps in Git | AI agents build, run and maintain the software on top of your existing systems |
| How it reaches Fortnox and HubSpot | Direct connections to databases and APIs, set up by the builder | Connects to the existing systems rather than replacing them |
| How numbers are produced | The builder writes the logic in JavaScript and SQL | Explicit queries or code run by a compute engine, not written by a language model |
| Access and audit | Role-based access controls, audit logging, SSO/SAML support and per-environment resource permissions | Access control, versioning, monitoring and audit history are part of the runtime |
Worked example: open Fortnox invoices next to HubSpot deals
Define one question and one matching rule
Illustrative example: finance and sales want one page per customer showing open Fortnox invoices next to open HubSpot deals, say for 40 active customers, matched on a customer number both teams already keep in both systems.
Connect Fortnox and HubSpot in an initial setup
In the initial setup, someone with admin rights in each system grants access. Source permissions, data mapping and reconciliation are necessary steps when connecting systems, so plan time to agree which fields mean the same thing in both.
Let an agent build the portal
In Ronja, AI can help build software, so in this example an agent builds the customer pages on the connected Fortnox and HubSpot data while the team describes what each page should show.
Match invoices to deals with code
The matching rule runs as executable program logic rather than AI interpretation, because it needs a fixed result. The aim in this example is that the same invoice and deal give the same match every time, and that the finance team can follow how the rule decides.
Review the result before relying on it
In this example, a finance controller compares the portal with Fortnox for ten customers, and the team starts using it only after that check. Invoices without a matching deal are listed for a person to resolve.
Compare with the Retool route
Built in Retool, the same portal typically starts with a builder setting up the Fortnox and HubSpot connections, writing the queries and the data model that join invoices to deals, and being named as the owner who fixes it when something changes.
Who owns and maintains an internal tool after launch
Every internal tool needs a named owner after launch, because the connections, rules and systems underneath it keep changing. Maintenance means keeping access working, adjusting logic when the business changes and answering when a number looks wrong.
Access can be one of the first things to stop working without anyone noticing. In Fortnox, the refresh token that an integration uses to generate a new access token has an expiration time of 45 days. Ask how your integration handles that expiry and who is notified if a connection stops working.
In Retool, ownership also shows up on the bill. Retool defines a builder as a user who created or edited an app or workflow in the billing cycle, and bills per builder, per month. Anyone who changes the portal in a given cycle therefore counts as a builder.
With an agent-built tool, the question moves from who can code to who decides. Someone in the business still owns the matching rules, reviews the results and decides when the definitions behind the numbers should change.
What to check in Fortnox and HubSpot before you build
- An active Fortnox integration licence
Fortnox requires an active integration licence on the subscription before an integration can be activated.
- Fortnox scopes and least privilege
Fortnox scopes give both read and write access to an endpoint, and read-only API access is not possible. Restrict what users can do in the tool built on top.
- The Fortnox rate limit
Fortnox allows 300 requests per minute per client ID and tenant, which in practice means 25 requests per 5 seconds. Ask how the tool reads data within that limit.
- The HubSpot access type
HubSpot uses static access tokens for apps installed in a single account at a time. Confirm which account the portal reads and who holds admin rights there.
- A shared customer key
Check that each customer can be matched across both systems, for example through a customer number kept in both. Without it, matching turns into manual work.
- A named reviewer
Decide who checks the first results against Fortnox and HubSpot before the team relies on the portal.
- Who is told if a connection stops working
Ask how the integration handles token expiry and who is notified if a connection stops working, so the portal does not go stale unnoticed.
Who an agent-built Retool alternative suits
For
- Finance, sales or operations teams in established companies with no developers on staff
- Teams that need one internal view across systems such as Fortnox and HubSpot
- Business leads who want to own the rules without owning the code
- Companies that want to start with one bounded process and grow from there
Not for
- Companies with their own development team that want to build everything themselves on AWS, Google Cloud or Azure
- Teams that only need a one-off report, where a spreadsheet export still does the job
When Retool remains the right choice
Retool remains the right choice when you have developers who want to own the code. Retool's own material says it is faster than building from scratch but not a replacement for real engineering, which is a strength when engineers do the building.
It also fits the kind of software it was made for. Retool says it is built for internal tools, admin interfaces, operational dashboards and business-facing portals, and that it is not the right tool for a consumer marketing site or a heavily custom-branded public web app.
So the deciding question is about people rather than features. If an engineer will build the portal, keep it in version control and stay around to change it, Retool gives that person a faster starting point than building from scratch. If nobody on the team writes code and the work runs between systems like Fortnox and HubSpot, the missing builder is the real gap, and an approach where agents build on the connected systems is likely the better fit.
If nobody on your team writes code, one bounded process is a reasonable place to compare the two routes.
Talk to us
Review one bounded process with Ronja.
Talk to usSources
Frequently asked questions
Can a non-technical team use Retool without hiring a developer?
It can work for simple apps if someone is willing to learn to write queries and code and look after the connections. In practice, teams without developers often end up depending on one trained colleague or an external consultant, and every change waits for that person. If nobody wants that role, compare options where the builder role is not needed at all.
How long does it take to build a Fortnox and HubSpot portal?
It depends less on the tool than on the data. The slow parts are usually agreeing how a customer is identified in both systems, arranging access in each system and checking the first results. Starting with one bounded view, such as open invoices next to open deals, keeps those steps small enough to finish and review.
What happens if the person who built our Retool app leaves?
The team keeps an app it can use but may not be able to change. Queries, connections and business rules usually live in what the builder wrote, so changes wait until someone new learns the app. While the builder is still there, write down the rules, the connections and who is told if a connection stops working, whichever tool you end up using.