Webapplicatie laten bouwen die uw werk echt sneller maakt

Een website is er om gelezen te worden; daar past een CMS als WordPress goed bij. Een webapplicatie is er om in te werken: inloggen, gegevens invoeren, statussen bijwerken, rechten per rol. Een native app hoort bij gebruik onderweg met camera, locatie, pushmeldingen of offline werken, en betekent app stores en reviewprocessen. Praktische test: als uw gebruikers vooral gegevens bewerken achter een inlog, is het een webapplicatie. Moeten ze dat buiten doen zonder stabiele verbinding, dan komt een app in beeld; zie /app-laten-ontwikkelen. In veel gevallen is een webapplicatie die op mobiel goed werkt genoeg, en houdt u een tweede codebase en storekosten uit uw begroting.

Een afgebakende interne webapplicatie die een bestaand proces vervangt begint rond 15.000 tot 30.000 euro. Een platform met meerdere rollen, een klantportaal en koppelingen naar bestaande systemen valt tussen 40.000 en 90.000 euro. Binnen die bandbreedte bepalen drie dingen de prijs: het aantal schermen, hoeveel uitzonderingen uw logica kent en hoeveel systemen mee moeten praten. Die uitzonderingen zijn meestal de grootste kostenpost, want elke afwijking op de hoofdregel is een extra pad dat gebouwd en getest moet worden. We noemen pas een bedrag na een korte discovery; voor een eerste indicatie is de calculator op /calculator sneller.

Een eerste werkende versie van een afgebakende applicatie leveren we doorgaans in 6 tot 10 weken. Een breder platform met meerdere modules en koppelingen loopt op naar 3 tot 6 maanden. We werken in sprints van twee weken; na elke sprint logt u in op een testomgeving en werkt u met wat er gebouwd is. Die momenten zijn er niet voor de vorm: de meeste wijzigingen komen van iemand die het echte werk doet en ziet dat een stap in de praktijk anders loopt dan op papier.

Vier vormen. Interne bedrijfstools waarin orders, voorraad, planning of urenregistratie samenkomen met rechten per rol. Klantportalen waarin uw klanten hun eigen bestellingen, documenten en facturen zien in plaats van erom te mailen. Dashboards die cijfers uit meerdere systemen naast elkaar zetten. En workflow- of goedkeuringssystemen die aanvragen uit de mailbox halen en er een controleerbaar spoor van maken. In alle vier gevallen zit de winst zelden in een mooiere interface, maar in het verdwijnen van dubbele invoer en zoekwerk.

We bouwen webapplicaties responsive, dus ze werken in de browser op desktop, tablet en telefoon zonder dat iemand iets installeert. Voor gebruik in het veld kunnen we er een progressive web app van maken: een eigen icoon op het startscherm, snel opstarten en beperkt doorwerken bij een slechte verbinding. Een PWA is niet genoeg zodra u echt offline moet werken met synchronisatie achteraf, zware camerafuncties of achtergrondlocatie nodig heeft, of afhankelijk bent van betrouwbare pushmeldingen op iOS. In die gevallen adviseren we een app naast de webapplicatie, met dezelfde backend erachter.

Vrijwel altijd, en het is vaak juist de reden dat een project rendeert. Heeft een systeem een API, dan koppelen we erop; heeft het die niet, dan werken we met imports, exports of een tussenlaag. Belangrijker dan de techniek is de vraag welk systeem de bron van waarheid is en wat er moet gebeuren als twee systemen elkaar tegenspreken. Die keuze maken we in de discovery. Hoe we koppelingen bouwen, testen en monitoren staat uitgebreid op /software-koppelingen.

Als uw proces niet uniek is, koopt u het beter. Voor boekhouding, salarisadministratie, e-mailmarketing en een informatieve website bestaan pakketten die beter en goedkoper zijn dan wat wij op maat maken; een WordPress-site met een goede structuur is voor content vaak precies genoeg. Maatwerk verdient zich terug wanneer uw werkwijze het onderscheid is waarvoor klanten bij u komen, wanneer u een pakket zo zwaar moet verbouwen dat elke update een risico wordt, of wanneer u per gebruiker betaalt voor iets waarvan u tien procent gebruikt. Komt u met een pakket weg, dan zeggen we dat in het eerste gesprek.

Rekenen helpt hier meer dan principes. Zet de licentiekosten per gebruiker over vijf jaar naast een eenmalige investering plus onderhoud, en tel het handwerk mee dat een standaardproduct niet wegneemt. Een abonnement is doorgaans de goede keuze bij een gangbaar proces, weinig gebruikers of een korte horizon. Eigen software wint bij veel gebruikers, een proces dat afwijkt van de norm of een koppeling die het pakket niet ondersteunt. Wilt u zelf software als dienst verkopen in plaats van gebruiken, dan is dat een ander traject; zie /webapplicatie-laten-bouwen.

Een webapplicatie staat op het open internet, dus de basis moet staan: versleuteld verkeer, wachtwoordbeleid met tweefactorauthenticatie, rechten die per rol op de server worden gecontroleerd en niet alleen in de interface, validatie van alle invoer en logging van gevoelige handelingen. Daarnaast houden we afhankelijkheden actueel, want de meeste incidenten komen niet door een creatieve aanvaller maar door een pakket dat een jaar niet is bijgewerkt. Voor omgevingen met persoonsgegevens hosten we binnen de EU en beperken we in het ontwerp wie welke gegevens ziet.

De code is van u en staat in een repository op uw eigen organisatie. Hosting zetten we op uw accounts: doorgaans Vercel of een Europese cloud, afhankelijk van waar uw data mag staan en welke eisen uw klanten stellen. De database hoort daarbij, met back-ups en een herstelplan dat we ook echt hebben getest in plaats van alleen de belofte dat er back-ups zijn. U kunt op elk moment een andere partij toegang geven zonder dat daar iets van ons voor nodig is.

Onderhoud is geen optie maar een gegeven: frameworks, browsers en beveiligingspatches blijven bewegen. We werken met een onderhoudsabonnement met een vast aantal uren per maand voor updates, monitoring, kleine verbeteringen en vragen van gebruikers. Uren die overblijven zetten we in overleg in voor doorontwikkeling. Verplicht is het niet: omdat code, hosting en documentatie op uw naam staan, kunt u het onderhoud ook intern of bij een andere partij beleggen. Wat we wel adviseren is jaarlijks budget reserveren, ongeacht wie het werk doet.

Beschrijf in een paar regels welk proces nu misgaat en wie ermee werkt, en stuur dat via /contact. We plannen een gesprek van een halfuur waarin we vooral vragen stellen. Neem mee waar u nu mee werkt: de Excel-bestanden, een schermafbeelding van het huidige systeem of het formulier waar het misloopt. Dat is nuttiger dan een uitgewerkt functioneel ontwerp. Daarna volgt een voorstel met scope, bandbreedte en mijlpalen, of een eerlijk advies dat een bestaand pakket u sneller helpt.