Vilket är ett bra alternativ till Retool för ett team utan utvecklare?

Varför Retool kör fast i ett team utan utvecklare

Retool förutsätter att någon i teamet skriver kod. Enligt Retools eget material är plattformen byggd för utvecklare först: du skriver JavaScript och SQL, kopplar direkt mot databaser och API:er och hanterar apparna i Git.

För ett ekonomi-, sälj- eller driftteam utan utvecklare finns då två vägar. Antingen lär sig någon tillräckligt mycket SQL och JavaScript för att bygga och ändra appen, eller så tar bolaget in en konsult. I båda fallen hamnar databasfrågorna, kopplingarna och kunskapen om hur appen fungerar ofta hos en enda person, och varje ändringsönskemål får vänta på just den personen.

Affärsreglerna tenderar också att flytta in i appen. Reglerna som avgör vad som räknas som en obetald faktura eller en aktiv affär hamnar ofta i appens databasfrågor, och där kan de vara svåra att läsa eller kontrollera för den som inte är utvecklare. När byggaren går vidare kan teamet bli kvar med en app som det kan använda men inte ändra.

Känns den flaskhalsen igen kan en genomgång av en avgränsad process visa om byggarrollen verkligen behövs.

Prata med oss

Granska en tydligt avgränsad process tillsammans med Ronja.

Så ser ett bra Retool-alternativ ut när du saknar utvecklare

Ett bra alternativ till Retool för ett team utan utvecklare tar bort byggarrollen i stället för att göra den lättare att lära sig. Verktyget ska byggas åt dig på de system du redan kör, hålla affärslogiken där de som äger den kan kontrollera den och fortsätta fungera utan en namngiven utvecklare bakom.

I praktiken ger det fyra test som du kan använda på varje alternativ du jämför.

Ronja är byggt kring den modellen: plattformen ansluts till de system ett företag redan har, som affärssystem, CRM och ekonomisystem, och bygger och driver mjukvara för arbetet som sker mellan systemen. När en agent bygger kan teamet lägga sin tid på att beskriva processen och granska resultatet i stället för att rita skärmar och skriva databasfrågor.

Att pröva de fyra testen på en avgränsad process hos dig är ett praktiskt sätt att jämföra alternativen.

• Verktyget ansluts till ditt affärssystem, CRM och ekonomisystem och låter dem vara kvar.
• Matchningar och summor räknas fram av kod, inte uppskattas av en språkmodell.
• Affärsdefinitionerna är gemensamma och kopieras inte in i varje app.
• Åtkomst, ändringar och övervakning ingår i plattformen.

Prata med oss

Granska en tydligt avgränsad process tillsammans med Ronja.

Retool jämfört med ett agentbyggt verktyg på Ronja

Exempel steg för steg: obetalda Fortnox-fakturor bredvid HubSpot-affärer

1. Bestäm en fråga och en matchningsregel

   Illustrativt exempel: ekonomi och sälj vill ha en sida per kund som visar obetalda fakturor i Fortnox bredvid öppna affärer i HubSpot, säg för 40 aktiva kunder, matchade på ett kundnummer som båda teamen redan för i båda systemen.

2. Koppla in Fortnox och HubSpot vid den första uppsättningen

   Vid den första uppsättningen ger någon med administratörsbehörighet i respektive system åtkomst. Behörigheter i källsystemen, mappning av data och avstämning är nödvändiga steg när system kopplas ihop, så planera tid för att enas om vilka fält som betyder samma sak i båda.

3. Låt en agent bygga portalen

   I Ronja kan AI hjälpa till att bygga mjukvara, så i det här exemplet bygger en agent kundsidorna på den anslutna datan från Fortnox och HubSpot medan teamet beskriver vad varje sida ska visa.

4. Matcha fakturor mot affärer med kod

   Matchningsregeln körs som exekverbar programlogik i stället för AI-tolkning, eftersom den måste ge ett bestämt resultat. Målet i det här exemplet är att samma faktura och affär ger samma matchning varje gång, och att ekonomiteamet kan följa hur regeln avgör.

5. Granska resultatet innan du förlitar dig på det

   I det här exemplet jämför en controller portalen med Fortnox för tio kunder, och teamet börjar använda den först efter den kontrollen. Fakturor utan matchande affär listas så att en person kan reda ut dem.

6. Jämför med vägen via Retool

   Byggs samma portal i Retool börjar det oftast med att en byggare sätter upp kopplingarna till Fortnox och HubSpot, skriver databasfrågorna och datamodellen som kopplar ihop fakturor och affärer, och blir utsedd ägare som rättar när något ändras.

Vem som äger och förvaltar verktyget när det är klart

Varje internt verktyg behöver en namngiven ägare efter lanseringen, eftersom kopplingarna, reglerna och systemen under det hela tiden förändras. Förvaltning betyder att hålla åtkomsten igång, justera logiken när verksamheten ändras och svara när en siffra ser fel ut.

Åtkomsten kan vara en av de första sakerna som slutar fungera utan att någon märker det. I Fortnox har den refresh-token som en integration använder för att skapa en ny access-token en giltighetstid på 45 dagar. Fråga hur din integration hanterar att den löper ut och vem som får besked om en koppling slutar fungera.

I Retool syns ägarskapet också på fakturan. Retool definierar en byggare som en användare som har skapat eller redigerat en app eller ett arbetsflöde under faktureringsperioden, och debiterar per byggare och månad. Den som ändrar portalen under en viss faktureringsperiod räknas därmed som byggare för den perioden.

Med ett agentbyggt verktyg flyttas frågan från vem som kan koda till vem som bestämmer. Någon i verksamheten äger fortfarande matchningsreglerna, granskar resultaten och avgör när definitionerna bakom siffrorna ska ändras.

Det här ska du kontrollera i Fortnox och HubSpot innan du bygger

• En aktiv integrationslicens i Fortnox

  Fortnox kräver en aktiv integrationslicens på abonnemanget innan en integration kan aktiveras.

• Scopes i Fortnox och minsta möjliga behörighet

  Scopes i Fortnox ger både läs- och skrivåtkomst till en endpoint, och det går inte att få enbart läsåtkomst via API:et. Begränsa därför vad användarna kan göra i verktyget som byggs ovanpå.

• Fortnox gräns för anrop

  Fortnox tillåter 300 anrop per minut per klient-id och Fortnox-konto, vilket i praktiken innebär 25 anrop per 5 sekunder. Fråga hur verktyget läser data inom den gränsen.

• Typen av åtkomst i HubSpot

  HubSpot använder statiska åtkomsttokens för appar som installeras i ett konto i taget. Bekräfta vilket konto portalen läser från och vem som har administratörsbehörighet där.

• En gemensam kundnyckel

  Kontrollera att varje kund går att matcha mellan systemen, till exempel genom ett kundnummer som finns i båda. Utan det blir matchningen manuellt arbete.

• En utsedd granskare

  Bestäm vem som kontrollerar de första resultaten mot Fortnox och HubSpot innan teamet förlitar sig på portalen.

• Vem som får besked om en koppling slutar fungera

  Fråga hur integrationen hanterar att tokens löper ut och vem som meddelas om en koppling slutar fungera, så att portalen inte blir inaktuell utan att någon märker det.

Vem ett agentbyggt alternativ till Retool passar

När Retool fortfarande är rätt val

Retool är fortfarande rätt val när du har utvecklare som vill äga koden. Enligt Retools eget material är plattformen snabbare än att bygga från grunden men ingen ersättning för riktig utveckling, och det är en styrka när det är utvecklare som bygger.

Retool passar också den sortens mjukvara plattformen är gjord för. Enligt Retool är den byggd för interna verktyg, administrationsgränssnitt, operativa dashboards och verksamhetsnära portaler, och inte rätt verktyg för en marknadsföringssajt mot konsumenter eller en publik webbapp med kraftigt anpassat varumärke.

Den avgörande frågan handlar alltså om människor snarare än funktioner. Om en utvecklare ska bygga portalen, hålla den under versionshantering och finnas kvar för att ändra den, ger Retool den personen en snabbare start än att bygga från grunden. Om ingen i teamet skriver kod och arbetet sker mellan system som Fortnox och HubSpot är det den saknade byggaren som är det verkliga gapet, och då passar troligen ett arbetssätt där agenter bygger på de anslutna systemen bättre.

Om ingen i ditt team skriver kod är en avgränsad process en rimlig plats att jämföra de två vägarna.

Prata med oss

Granska en tydligt avgränsad process tillsammans med Ronja.

Källor

• Retool – What engineers build in Retool
• Retool – Pricing
• Fortnox – Authorize your integration
• Fortnox – Rate limits for Fortnox API
• Fortnox – Scopes
• Fortnox – Kom igång med integrationer
• HubSpot – Authentication overview
• Ronja – Deterministic by design
• Ronja – Ronja platform
• Ronja – Ronja data foundation