Aanvraag klant A
DEMO-101 · eigenaar DEMO-KLANT-A
- Bekijken: toegestaan
- Wijzigen: toegestaan
- Exporteren: geblokkeerd
Applicatie in de browser
Een webapplicatie laten maken rond één helder proces.
Een maatwerk webapplicatie laat gebruikers in de browser taken uitvoeren, gegevens verwerken en status volgen. Een gewone website legt vooral informatie uit, een mobiele app wordt voor een apparaatplatform geïnstalleerd, een portaal is afgeschermde toegang voor een doelgroep en SaaS is een breder product- en exploitatiemodel.
Wat is een webapplicatie?
Een webapplicatie is interactieve software die via een browser wordt gebruikt. Ze kan bijvoorbeeld rollen, invoer, status, goedkeuringen of dashboards ondersteunen, zonder automatisch een mobiel app-storeproduct of SaaS-bedrijf te zijn.
Rechten vóór schermen
Wie mag welk record gebruiken?
Maak de eerste versie van je rechtenmatrix. Kies per rol geen toegang, alleen eigen records of alle records binnen de afgesproken omgeving. Bekijk het gevolg voor twee verzonnen aanvragen en download de afspraken als CSV.
Veeg de matrix horizontaal om alle acties te zien. Met een toetsenbord kun je de matrix focussen en horizontaal scrollen.
| Rol | Bekijken | Wijzigen | Exporteren |
|---|---|---|---|
De voorbeeldgebruiker is DEMO-KLANT-A. Je rol verandert, het eigenaarschap van de aanvragen niet.
Een actie vereist ook toegang om hetzelfde record te bekijken. Geef je exportrechten voor alle records maar alleen zicht op eigen records, dan blijven de andere records geblokkeerd.
Aanvraag klant B
DEMO-102 · eigenaar DEMO-KLANT-B
- Bekijken: geblokkeerd
- Wijzigen: geblokkeerd
- Exporteren: geblokkeerd
Alle gegevens zijn demonstraties. Dit is een eisenblad, geen beveiligd portaal. De echte applicatie moet eigenaarschap en rechten op de server controleren, ook bij directe API-verzoeken. Tenantgrenzen, veldrechten en audit staan nog open.
Bespreek je portaal met deze rechtenmatrix · voeg de TXT-versie handmatig toe aan je aanvraag. De CSV is voor je spreadsheet.
Een maatwerk webapplicatie past wanneer
- bekende gebruikers in de browser een terugkerende taak of workflow moeten afronden
- rollen, gegevens, beslisregels, uitzonderingen en een proceseigenaar voldoende duidelijk zijn
- onderhouden standaardsoftware de kritieke workflow structureel niet ondersteunt
- de organisatie verantwoordelijkheid kan dragen voor beveiliging, beheer en verdere ontwikkeling
Kies eerst een eenvoudiger of beter passende vorm wanneer
- de behoefte vooral publieke informatie, vindbaarheid of contact is en een website volstaat
- een onderhouden pakket of beperkte configuratie de kernworkflow al verantwoord ondersteunt
- het proces voortdurend verandert of gebruikers en eigenaarschap nog niet duidelijk zijn
- bestaande systemen alleen gecontroleerd gegevens hoeven uit te wisselen en een API-koppeling volstaat
- de vereiste werking op locatie nog niet op de beoogde apparaten en bij verbindingsverlies is onderzocht
Voorbeeldworkflow
Personeel in- en uitchecken
Medewerker checkt in
Dienst wordt actief
Supervisor ziet aanwezigen
Afwijkingen worden gemarkeerd
Uitcheck sluit de dienst af
Servicebedrijf
Nieuwe aanvraag
Medewerker toegewezen
Status bijgewerkt
Klant krijgt melding
Taak afgerond
Kies de vorm vanuit het gebruik
Website, standaardsoftware, koppeling, webapp of mobiele app?
De gewenste functielijst bepaalt de vorm niet. Kijk eerst wie wat moet doen, waar het werk plaatsvindt en welke bestaande oplossing al beschikbaar is.
| Situatie | Kleinste passende vorm | Waarom |
|---|---|---|
| Bezoekers moeten vooral informatie vinden, vertrouwen opbouwen of contact opnemen | Website | De kern is publieke communicatie, geen operationele gebruikersworkflow |
| Een onderhouden product ondersteunt de kritieke taak met verantwoorde configuratie | Standaardsoftware of beperkte no-code-inrichting | Minder eigen bouw, beveiliging, onderhoud en overdracht |
| Bestaande systemen moeten vooral afgesproken gegevens uitwisselen | Gerichte API-koppeling | De systemen blijven de gebruikersomgeving; de verbinding is het ontbrekende onderdeel |
| Bekende gebruikers werken met rollen, invoer, regels, status en uitzonderingen in de browser | Webapplicatie op maat | De interactieve workflow en gegevensstaat vormen samen het product |
| Offline gebruik, push, camera, locatie of distributie via een app store is bepalend | Mobiele app of een afzonderlijk onderzochte PWA | Apparaat- en distributie-eisen sturen de technische vorm |
Passend aanbod in het kort
Solution Sprint
Betaald scopeonderzoek€1.250 excl. btw
Een organisatie met een niet-standaard proces- of productvraag die eerst gebruikers, afhankelijkheden, risico's en scope moet onderzoeken.
Zelfstandig onderzoekswerk dat het probleem, de gebruikers, afhankelijkheden, risico's en scope verduidelijkt voordat een realisatieprijs wordt afgegeven.
- Een probleem- en procesworkshop van 60–90 minuten
- Proceskaart van de huidige situatie
- Definitie van gebruikers en belanghebbenden
Implementatie niet inbegrepen
Jaarplannen voor digitaal werk
Past dit in een breder jaarplan?
Wanneer software, automatisering en koppelingen samen één jaar werk vormen, kan COMPANY (vanaf €5.000 per jaar excl. btw) de implementatie en het doorlopende werk bundelen. Het voorstel kiest wat nodig is.
COMPANY
Bouw rond hoe jouw bedrijf werkt.
Vanaf €5.000 per jaar excl. btw
Een afgebakend technologieplan voor je website, specialistische content en SEO, interne software, automatisering, mobiele apps, AI en verbonden hardware.
Het voorstel kiest de bouwstenen; niet alles zit in de startprijs.
- Een schriftelijk voorstel dat de bouwstenen kiest die jouw bedrijf nodig heeft
- Afgebakende implementatie voor het planjaar
- Afgesproken doorlopend werk: beheer, onderhoud en afgesproken verbeteringen
COMPANY is geen losse onderzoeksfase: het plan omvat implementatie en doorlopend werk. De Solution Session en Solution Sprint blijven apart en optioneel.
Liever alleen deze module?
Dat kan. Vraag deze module los aan, zonder jaarplan. Een betaalde Solution Session of Sprint is optioneel.
Vraag deze module los aan: Webapplicatie, dashboard of portaalVergelijk de plannen
Eenmalige projectraming
Bereken een los digitaal project
Voor een project zonder jaarplan. Kies wat je wilt laten maken; het formulier toont alleen de keuzes die bij dat product horen. Deze eenmalige raming staat los van de jaarplannen en wordt er nooit bij opgeteld.
Eenmalig · indicatie, geen offerte · bedragen excl. btw · externe kosten worden pas na scope bevestigd
Vanaf
€5.000
eenmalig · excl. btw · indicatie
- Startconfiguratie
- €5.000
Care na opleveringNiet gekozen
Hosting, externe diensten, licenties en betaalproviderkosten zijn niet inbegrepen. De offerte kan afwijken na controle van techniek, planning, content en afhankelijkheden. Bij veel onzekerheid kan eerst de optionele Solution Sprint van €1.250 excl. btw passen.
Bespreek deze webappProjectstatus
Case study: Brengo
Een browserapp voor lokale transporttaken in Groningen, met aparte rollen voor aanvragers en providers, taakstatus, chat, routecontext en een zichtbare betaalstatus. Beschermde workflows vragen om inloggen.
Vergelijk browsergebruik met werk op een apparaat
Een inlogscherm bepaalt nog niet of een browserapp de juiste vorm is. Beschrijf waar gebruikers werken, welke apparaatfuncties nodig zijn en wat er zonder verbinding moet gebeuren. Gebruik die situaties om webapp en mobiele app te vergelijken voordat je techniek kiest.
Breng de kritieke workflow in kaart
Een webapplicatie begint niet bij schermen, maar bij één gebruiker die een herkenbare taak van begin tot einde moet kunnen afronden. Leg vast wat de handeling start, welke informatie nodig is, welke regels gelden, welke status na iedere stap zichtbaar moet zijn en wanneer het werk werkelijk klaar is. Rollen en rechten horen daarbij: niet iedere gebruiker mag dezelfde gegevens zien, wijzigen of goedkeuren.
Breng ook de afwijkende route vroeg in beeld. Ontbrekende invoer, dubbele aanvragen, een geweigerde goedkeuring, een uitgevallen koppeling of een handmatige correctie zijn geen latere details. De eerste versie bewijst daarom één volledige kernworkflow inclusief een veilige uitzondering en herstelroute. Extra dashboards, meldingen of beheerfuncties volgen alleen wanneer gebruik en bedrijfswaarde dat rechtvaardigen.
- Gebruiker, doel en aanleiding van de taak
- Invoer, gegevensbron en gewenste uitvoer
- Rollen, rechten, regels en goedkeuringsmomenten
- Status, uitzonderingen en herstelroute
- Proceseigenaar en meetbaar acceptatiebewijs
Illustratieve voorbeelden van webapplicaties
Een klantenportaal kan een bekende klant documenten, aanvragen en status laten beheren. Een interne toepassing kan intake, beoordeling en goedkeuring door vaste rollen leiden. Een planningstool kan taken en uitzonderingen rond een gedeelde werkvoorraad zichtbaar maken. Een dashboard wordt pas een webapp wanneer gebruikers vanuit de informatie ook een beheerste actie kunnen uitvoeren, in plaats van alleen cijfers te bekijken.
Ook een spreadsheetproces kan aanleiding zijn voor een gerichte webapp, bijvoorbeeld wanneer meerdere gebruikers gelijktijdig invoeren, rechten verschillen of wijzigingen traceerbaar moeten zijn. Dit zijn illustratieve patronen, geen klantcases, ondersteunde templates of beloofde resultaten. De passende vorm volgt uit de werkelijke gebruikers, gegevens, uitzonderingen en bestaande software.
- Klantenportaal laten maken: bepaal welke eigen aanvragen, documenten en statussen een klant mag bekijken of wijzigen. Test ook dat gegevens van een andere klant onbereikbaar blijven.
- Ledenportaal laten maken: leg vast wie lidmaatschap en toegang beheert, wat na beëindiging gebeurt en welke gegevens een medewerker mag corrigeren.
- B2B-portaal: beschrijf rechten per organisatie én per medewerker. Wie mag namens het bedrijf aanvragen indienen of akkoord geven, en wie kan dat recht intrekken?
- Intern dashboard laten maken: begin bij de beslissing die iemand moet nemen. Voor alleen cijfers bekijken kan een bestaande rapportagetool volstaan; acties, goedkeuringen en wijzigingen vragen aanvullende regels en acceptatietests.
Wanneer is een webapplicatie op maat verantwoord?
Een maatwerk webapplicatie is verantwoord wanneer de kritieke workflow aantoonbaar afwijkt van wat onderhouden standaardsoftware ondersteunt en die afwijking belangrijk genoeg is om eigen bouw en beheer te dragen. Configuratie, een bestaande module of een beperkte no-codeoplossing heeft de voorkeur wanneer daarmee de taak veilig en beheersbaar wordt opgelost. Maatwerk is geen doel op zichzelf.
Een webapp laten maken betekent ook dat keuzes over rollen, gegevens, beveiliging, testen, hosting en onderhoud niet langer volledig bij een pakketleverancier liggen. Daarom moet de organisatie een product- en proceseigenaar aanwijzen en prioriteiten kunnen stellen. Zonder die verantwoordelijkheid groeit een kleine web applicatie gemakkelijk uit tot een onbeheerste wensenlijst.
Hoe laat je een webapp bouwen?
Eerst worden het probleem, de huidige werkwijze, gebruikers en gewenste uitkomst onderzocht. Daarna volgen de kritieke workflow, gegevens, rollen, afhankelijkheden, risico’s en scopegrenzen. Een klikbaar prototype, technische proef of systeemdiagram kan de onzekerste aanname toetsen voordat realisatie wordt geoffreerd. Het doel is niet een volledig product simuleren, maar vroeg ontdekken of de belangrijkste taak begrijpelijk en technisch verantwoord is.
Als de scope voldoende bewijs heeft, kan een eerste versie afgebakend worden gerealiseerd. Normale routes, rechten, validatie, uitzonderingen en herstel worden getest met representatieve scenario’s. Ingebruikname omvat alleen wat schriftelijk is afgesproken, inclusief overdracht en beheergrenzen. Verbeteringen na werkelijk gebruik worden als nieuwe keuzes geprioriteerd; ze zijn niet stil bij de oorspronkelijke bouw inbegrepen.
- Probleem, gebruikers en huidige workflow onderzoeken
- Rollen, data, afhankelijkheden en risico’s begrenzen
- Kritieke interactie of technische onzekerheid toetsen
- Afgebakende realisatie en acceptatiescenario’s vastleggen
- Ingebruikname, overdracht en vervolgkeuzes expliciet maken
Eerst zelfstandig scopewerk
De Solution Sprint is geen verlengd verkoopgesprek
De Solution Sprint is geen verlengd verkoopgesprek. Het is zelfstandig projectwerk waarmee het probleem, de gebruikers, afhankelijkheden, risico’s en scope worden onderzocht voordat een realisatieprijs wordt afgegeven.
Implementatie is niet inbegrepen. Je bent niet verplicht om de implementatie daarna bij OmniTechs onder te brengen en er wordt geen realisatieprijs beloofd voordat het benodigde scopewerk is afgerond. Als een eenvoudiger bestaande oplossing voldoende is, bevelen we die aan.
Wat bepaalt scope, kosten en doorlooptijd?
De kosten van een webapplicatie laten maken hangen samen met het aantal gebruikersrollen, workflows, schermen, regels en uitzonderingen. Datamodellen, migratie, koppelingen, authenticatie, privacy, rapportage, volumes, prestaties en toegankelijkheid kunnen de scope verder beïnvloeden. Ook testdekking, productie-inrichting, documentatie en de afgesproken overdracht zijn echt werk; een korte lijst met functies zegt daar weinig over.
De doorlooptijd wordt daarnaast bepaald door beschikbare beslissers, inhoudelijke input, toegang tot systemen en snelheid van feedback. Daarom publiceert deze pagina geen generieke implementatieprijs of standaard aantal weken. De vaste Solution Sprint heeft een eigen goedgekeurde prijs en levergrens. Realisatie wordt alleen na voldoende scopeonderzoek afzonderlijk en schriftelijk geoffreerd.
Beveiliging, beheer en eigendom na ingebruikname
Beveiliging begint met passende authenticatie, minimale rechten en duidelijke scheiding tussen rollen. Er wordt vastgesteld welke gegevens werkelijk nodig zijn, welke acties gevoelig zijn en welke status voor controle of herstel zichtbaar moet blijven. Testen richt zich niet alleen op de normale route, maar ook op ongeldige invoer, ongeautoriseerde handelingen, tijdelijke uitval en herstel. Concrete maatregelen volgen uit het risico en de schriftelijke scope; er wordt geen algemene certificering of beveiligingsgarantie beloofd.
Hosting, monitoring, back-ups, updates, incidenten en ondersteuning hebben ieder een eigenaar en grens nodig. Bedrijfsdata en bedrijfscontent blijven van de klant. Eigendom en gebruik van specificaties, broncode, configuratie, documentatie, licenties en overige onderdelen worden vóór realisatie schriftelijk vastgelegd. Doorlopend onderhoud, nieuwe functies en migratie naar een andere omgeving zijn niet onbeperkt inbegrepen.
Een webapp is niet automatisch een PWA, mobiele app of SaaS-product
Een progressive web app kan vanuit de browser extra installeerbaar of apparaatgericht gedrag bieden, maar ondersteuning verschilt per apparaat en functie. Offline gebruik, pushmeldingen, camera, locatie en app-storedistributie moeten daarom afzonderlijk worden onderzocht. De term PWA is geen belofte dat iedere mobiele behoefte zonder native app kan worden opgelost.
SaaS beschrijft bovendien een product- en exploitatiemodel, niet alleen techniek in de browser. Meerdere klanten of tenants, onboarding, abonnementen, facturatie, support, beveiliging en operationeel beheer vergroten de verplichtingen. Een SaaS-idee begint daarom bij bewijs voor één doelgroep en één terugkerend probleem; deze route maakt van ieder webapp-project niet automatisch een SaaS-product.
Wie mag een aanvraag naar de volgende status zetten?
In een illustratief klantportaal kan een klant een aanvraag aanvullen, terwijl alleen een beoordelaar akkoord geeft. Ontbreekt een verplicht document, dan blijft de aanvraag bij de juiste verantwoordelijke staan. Beschrijf zulke beslissingen vóór je schermen bestelt: ze bepalen rollen, invoercontroles en uitzonderingen.
Veelgestelde vragen over webapplicaties
Wat is een webapplicatie?
Interactieve software die in een browser taken en gegevensverwerking ondersteunt.
Wat is het verschil met een gewone website?
Een website communiceert vooral informatie; een webapplicatie verwerkt invoer, status, regels of samenwerking.
Wat is het verschil met een mobiele app?
Een mobiele app wordt voor een platform geïnstalleerd en kan diepere apparaatfuncties gebruiken; een webapp draait via een browser en is vaak eenvoudiger breed beschikbaar.
Wanneer is een klantenportaal geschikt?
Wanneer een bekende klantgroep veilig eigen gegevens, documenten, taken of status moet kunnen bekijken of wijzigen.
Hoe bouw ik een webapp?
Wie een webapp laat maken, begint met het probleem, de gebruikers en één kritieke workflow. Daarna worden gegevens, rollen, uitzonderingen, risico’s en beheergrenzen vastgelegd en waar nuttig met een prototype of technische proef getoetst. Pas met voldoende bewijs volgt een afzonderlijk realisatievoorstel.
Wat kost een webapplicatie laten maken?
Dat hangt onder meer af van rollen, workflows, schermen, regels, uitzonderingen, data, migratie, koppelingen, beveiliging, toegankelijkheid, testen, hosting en onderhoud. Een eerste niet-bindende vanafprijs bereken je op de prijzenpagina; de implementatieprijs volgt pas nadat de scope voldoende is onderzocht.
Hoe lang duurt het om een web app te laten maken?
De duur volgt uit de gevalideerde scope, technische onzekerheden, beschikbare input, beslismomenten, testen en overdracht. Deze pagina belooft daarom geen standaard aantal weken voor implementatie.
Wanneer is standaardsoftware of no-code voldoende?
Wanneer een onderhouden oplossing de kritieke workflow, rechten, gegevens en uitzonderingen verantwoord ondersteunt en de resterende omwegen minder zwaar wegen dan eigen bouw en beheer.
Kan een webapplicatie met bestaande systemen koppelen?
Ja, wanneer de systemen passende toegang bieden en bronregels, rechten, datamapping, fouten en onderhoud zijn onderzocht. De technische integratie wordt als eigen afhankelijkheid en scopeonderdeel behandeld.
Hoe worden beveiliging en privacy bepaald?
Op basis van gebruikers, rollen, gevoelige handelingen, noodzakelijke gegevens, dreigingen, herstelbehoefte en toepasselijke afspraken. Concrete maatregelen en verantwoordelijkheden worden per project vastgelegd; er geldt geen algemene garantie voor iedere webapp.
Wie bezit de data, specificaties en opgeleverde onderdelen?
Bedrijfsdata en bedrijfscontent blijven van de klant. Eigendom en gebruik van specificaties, broncode, configuratie, documentatie, licenties en overige onderdelen worden vóór realisatie schriftelijk vastgelegd.
Wie regelt hosting, onderhoud en updates?
Dat wordt vóór realisatie afgesproken. Hosting, monitoring, back-ups, incidenten, defecten, updates en nieuw werk hebben ieder een eigenaar en supportgrens nodig; onbeperkte doorlopende ondersteuning wordt niet verondersteld.
Wanneer past een progressive web app of mobiele app beter?
Wanneer offline gedrag, pushmeldingen, camera, locatie, intensief telefoongebruik of app-storedistributie bepalend zijn. Of een PWA die behoefte betrouwbaar afdekt, moet per apparaat en functie worden onderzocht.
Wanneer is een SaaS-product te groot als eerste stap?
Wanneer multi-tenant beheer, facturatie, support, marktvalidatie en operationele verplichtingen nog niet zijn bewezen. Test dan eerst de kritieke workflow.