Hoe één persoon een tool van $40k per jaar verving door iets dat ze in een dag bouwde

Marta leidde de operatie voor een logistiek bedrijf van 30 personen in Guadalajara. Haar team gebruikte een enterprise-projectmanagementplatform dat hun zo’n $40.000 per jaar kostte — licenties per gebruiker, premium-tier voor de rapportagefuncties, plus een consultant die ze twee jaar geleden hadden ingehuurd om de eerste workflows op te zetten.

Dit is het ding dat niemand in het team hardop wilde zeggen: ze gebruikten er misschien 15% van.

Chauffeurs registreerden hun dagelijkse routes in de tool. Dispatchers checkten een Kanban-bord om te zien wie beschikbaar was. Marta trok een wekelijks rapport dat de tijdige leveringen en open kwesties toonde. Dat was het. De Gantt-grafieken, resource leveling, sprintplanning, urenregistratie en portfoliodashboards? Niemand raakte ze aan. Ze betaalden voor een Zwitsers zakmes om enveloppen te openen.

Het moment dat het kwartje viel

De contractverlenging kwam in februari. Marta had zichzelf al meer dan een jaar wijsgemaakt dat ze “volgend kwartaal” naar iets goedkopers zou migreren. Maar deze keer vertelde een vriendin die een klein e-commercemerk runde haar iets dat bleef hangen: “Ik ben gestopt met zoeken naar de juiste tool en heb gewoon aan een AI beschreven wat ik nodig had. Hij bouwde het.”

Marta was geen ontwikkelaar. Ze had ooit een Python-cursus gevolgd en die na week drie laten varen. Maar ze begreep haar eigen workflows beter dan wie dan ook. Ze kon precies beschrijven wat haar team nodig had omdat ze elke dag in die processen leefde.

Ze besloot te proberen zelf een vervanging te bouwen voordat ze de verlenging tekende.

Wat ze daadwerkelijk bouwde

Marta ging op een zaterdagochtend zitten met een AI-app-bouwer en begon stuk voor stuk te beschrijven wat ze nodig had.

Een scherm om routes te registreren. Chauffeurs moesten aan het begin van hun dienst inchecken, hun toegewezen stops zien en elke stop als voltooid markeren. Geen drag-and-drop-Gantt-onzin — gewoon een lijst met vinkjes en een tijdstempel. Ze beschreef dit in gewoon Spaans en zag de app-bouwer een werkende interface met een database erachter genereren.

Een dispatcherdashboard. Eén pagina die toonde welke chauffeurs actief waren, hoeveel stops ze nog hadden, en een kleurgecodeerde indicator of ze op schema lagen. Marta beschreef de logica: groen als ze tegen het middaguur minstens 60% van de stops hadden voltooid, geel als tussen 40-60%, rood daaronder. De bouwer vertaalde dit naar voorwaardelijke opmaak en een live bijgewerkte weergave.

Een wekelijks rapport. De cijfers die Marta elke vrijdag echt trok: totaal aantal leveringen, percentage op tijd, door chauffeurs gemelde kwesties (zoals een fout adres of een klant die niet thuis was), en een vergelijking met de vorige week. Ze vroeg de bouwer om een samenvattingstabel en een eenvoudige staafgrafiek te genereren. Dat deed hij.

Een eenvoudige issue tracker. Wanneer een chauffeur iets meldde — fout adres, beschadigd pakket, klacht van klant — moest het ergens terechtkomen waar Marta het kon zien en toewijzen. Geen volledig ticketingsysteem. Gewoon een lijst met een status (open / bezig / opgelost) en de mogelijkheid om een notitie toe te voegen.

Het hele ding kostte ongeveer acht uur, verspreid over zaterdag. Niet omdat een afzonderlijk stuk moeilijk was, maar omdat Marta bleef verfijnen. De eerste versie van het dispatcherdashboard toonde te veel data. Ze snoeide erin. Het scherm om routes te registreren had een optie “stop overslaan” nodig waar ze aanvankelijk niet aan had gedacht. Ze voegde hem toe door de wijziging te beschrijven.

Wat $40.000 eigenlijk kocht

Toen Marta haar app met vier schermen vergeleek met het enterprise-platform, was het verschil overduidelijk — maar niet in de richting die ze verwachtte.

De enterprise-tool had honderden functies en vereiste een consultant om te configureren. Marta’s app had vier schermen die direct aansloten op hoe haar team al werkte. Geen training nodig. Geen configuratieschuld.

Maar de echte kosten van de enterprise-tool waren nooit het abonnement. Het was de frictie waar haar team elke dag omheen werkte. Dispatchers coördineerden via WhatsApp omdat het vier taps kostte om in de mobiele app een leverstatus bij te werken. Marta hield een aparte Google Sheet bij voor het wekelijkse rapport omdat de ingebouwde rapportagemodule drie menu’s vereiste om dezelfde vijf cijfers te trekken. De chauffeurs hadden een workaroundpagina in de helpdocumentatie gebookmarkt voor het scherm om routes te registreren, omdat de standaardflow uitging van projectfases die ze niet gebruikten.

Marta’s app had geen workarounds omdat hij gebouwd was vanuit de workarounds. Elk scherm bestond omdat iemand in het team die taak informeel had gedaan — op WhatsApp, op een spreadsheet, op een whiteboard — en Marta de informele versie gewoon aan de bouwer beschreef.

De delen die haar verrasten

Drie dingen die Marta niet had verwacht:

Itereren ging snel. Toen een chauffeur voorstelde om bij elke stop een notitieveld toe te voegen, beschreef Marta de wijziging tijdens haar lunchpauze aan de bouwer en deployde hem die middag. Met de enterprise-tool gingen wijzigingen als deze door een supportticketwachtrij en duurden ze soms weken.

Haar team nam hem meteen in gebruik. Geen trainingssessies. Geen “kijk alsjeblieft deze onboardingvideo.” De dispatchers openden hem maandagochtend en begrepen hem omdat hij eruitzag als het whiteboard dat ze informeel gebruikten, alleen digitaal.

Ze bleef hem verbeteren. In de volgende twee weken voegde ze een vijfde scherm toe: een maandweergave voor haar baas met levertrends en geschatte kosten per route. Met de enterprise-tool zou dit een aanvraag voor een aangepast rapport zijn geweest. Met haar eigen app was het een gesprek van 20 minuten met de bouwer.

Wat dit niet is

Dit is geen verhaal over enterprise-software die slecht is. Als je een bedrijf van 500 personen bent dat complexe cross-functionele projecten draait met afhankelijkheden, resourcebeperkingen en compliance-eisen, heb je dat Zwitserse zakmes waarschijnlijk nodig.

Maar als je een team van 30 personen bent dat 15% gebruikt van een tool die meer kost dan een van je werknemers, dan is er iets niet in lijn. De tool is niet het probleem — de mismatch is het probleem.

En die mismatch was vroeger onvermijdelijk. Voordat je een app zonder te programmeren kon bouwen, waren je keuzes: betalen voor de grote tool, iets in elkaar knutselen in spreadsheets, of een ontwikkelaar inhuren om maatwerksoftware te bouwen (wat zijn eigen kosten en tijdlijn met zich meebrengt). Nu is er een vierde optie: beschrijf wat je nodig hebt en bouw het zelf.

De rekensom

Marta’s cijfers na één maand:

• Enterprise-tool: ~$3.300/maand ($40k/jaar)
• Abonnement AI-app-bouwer: onder de $100/maand
• Bouwtijd: 8 uur (één zaterdag)
• Tijd om te itereren: 20-30 minuten per wijziging
• Adoptietijd team: nul — ze snapten het op dag één

Ze had geen CTO of engineeringteam nodig. Ze moest beschrijven hoe haar team echt werkt — en een AI-app-bouwer die die beschrijving omzette in werkende software.

Waar je over moet nadenken

Als je je eigen situatie herkent in Marta’s verhaal, is hier een nuttige oefening voor je volgende softwareverlenging: schrijf elke functie op die je daadwerkelijk gebruikt in je huidige tool. Niet de functies waarvan je denkt dat je ze zou moeten gebruiken of ooit van plan bent te gebruiken. Degene die je team elke week aanraakt.

Als die lijst op een post-it past, betaal je misschien te veel voor complexiteit die je niet nodig hebt.

Je hoeft de vervanging niet in een dag te bouwen. Je zou kunnen beginnen met één scherm — degene die er het meest toe doet — en kijken hoe het voelt. De kosten van het proberen zijn een paar uur. De kosten van het niet proberen zijn nog een jaar betalen voor functies die je nooit zult aanraken.

Wil je zien hoe het bouwen van je eigen tool eruitziet, probeer dan Proyecta en begin met het ding waar je team het meest over klaagt.