Een productieklare econometrie-app die uw R- of Python-modellen toegankelijk maakt voor consultants, analisten en bestuurders. Multi-user, validatie-flow en regulator-rapportage. Geen losse Shiny-prototype meer, maar een omgeving die u kunt uitrollen, verkopen of intern opschalen.
De modellen komen uit het brein van uw quants — statistische tijdreeksen, Bayesiaanse priors, regressieboom-ensembles, soms reinforcement-learning of agentenmodellen. Maar zodra die modellen gebruikt moeten worden door iemand die geen R-prompt openzet, beginnen de échte problemen: parameter-validatie, versie-beheer, autorisatie per scenario, reproducibiliteit van een draaiing van vorige maand, en een audit-trail die DNB of de AFM accepteert.
Wij bouwen econometrie-apps voor quant-consultancies, beleids- en research-instituten, verzekeraars met een actuarieel team, banken met PD/LGD/EAD-modellen, pensioenfondsen met ALM-vraagstukken, energie- en utility-bedrijven, en adviesbureaus die hun scenario-modellen white-label aan klanten leveren. Geen klikbaar prototype dat ergens half doet wat het moet doen — een productie-omgeving die in uw modelleer-, validatie- en governance-workflow klikt. Voor enterprise asset managers vervangen we Domino Data Lab of Databricks niet; we bouwen de specifieke schakels die het platform niet dekt, zoals een klantgericht model-frontend, een rapportage-engine voor toezichthouders of een API-laag waardoor uw eigen klanten de modellen kunnen consumeren.
De markt onder ons — kleine onderzoeksgroepen, individuele consultants — leunt op R Shiny, Streamlit of Dash. Dat werkt prima voor één onderzoeker met één model. De markt boven ons — grote banken, Robeco, ASR — bouwt zelf op SAS, Domino of een eigen JupyterHub-stack. Daartussenin zit een groep waar Shiny te limited is en zelfbouw te duur: mid-market quant-consultancies, research-instituten die hun modellen breder willen ontsluiten, en verzekeraars of pensioenfondsen die hun actuariële tools naar productie-grade UX willen tillen. Daar zit onze sweet spot.
Concreet werken we voor doelgroepen als kwantitatief-consultancybureaus die R- en Python-modellen voor klanten productioneren, beleids- en research-instituten in de stijl van CPB, NIBUD, RIVM of PBL die hun scenario-modellen toegankelijk willen maken voor beleidsmedewerkers en stakeholders, verzekeraars met een actuarieel team rondom Solvency II-pijler-berekeningen, banken die hun PD-, LGD- en EAD-modellen voor IRB-doeleinden willen ontsluiten, pensioenfondsen en uitvoeringsorganisaties met asset-liability-vraagstukken, energie- en utility-bedrijven met vraag- en prijsvoorspellingsmodellen, adviesbureaus die impact-assessments en scenario-analyses leveren, universiteiten die onderzoeksoutput zelf-bedienbaar willen maken voor partnerinstellingen, B2B-data-aanbieders die hun modellen als service willen verkopen, marketing- en mediabureaus met media-mix-modeling, en sport-analytics-leveranciers die werken in de Hudl- of Oodle-context. Niet elk traject vraagt om hetzelfde — een MMM-platform voor een mediabureau is een ander beest dan een ALM-tool voor een pensioenfonds — maar de onderliggende techniek-stack en governance-uitdagingen overlappen sterk.
Afhankelijk van wie het model gebruikt en welke governance erop zit. We adviseren welke variant past in het eerste gesprek — vaak ligt de waarde in de combinatie van een productie-grade UI plus een API-laag plus een nette compliance-overlay.
Uw quants hebben een model dat werkt in een notebook of Shiny-prototype, en u wilt het uitrollen naar interne gebruikers zonder dat zij RStudio openen. We pakken het script, refactoren het tot een schone module, bouwen er een React- of Vue-frontend omheen, en draaien de berekeningen in een cloud-runtime. Inclusief parameter-validatie, scenario-opslag en exports naar Excel of PDF.
Voor research-teams en actuariële afdelingen waar meerdere analisten met dezelfde modellen werken. Rolgebaseerde toegang per scenario, model-versie-beheer, een review-flow voor wie modellen mag publiceren, en een audit-trail die elke parameter-wijziging en elke berekening registreert. Geschikt voor IRB-modellen, Solvency II-pijler-berekeningen of beleids-impact-analyses waar reproduceerbaarheid een harde eis is.
Voor consultancies en data-aanbieders die hun modellen niet alleen intern gebruiken maar verkopen aan klanten. Een REST- of gRPC-API met OAuth-authenticatie, tenant-isolatie en rate-limits, plus een white-label-frontend per klant met eigen branding. Geschikt voor media-mix-modeling-bureaus, sport-analytics-leveranciers, of B2B-data-aanbieders die hun model-output als SaaS willen ontsluiten.
Een productieklare econometrie-app, plus de bouwblokken die u nodig heeft om de modellen zelf te beheren, te valideren en door te ontwikkelen.
Vier patronen waarin we klanten begeleiden — herkent u er één, dan praten we graag verder. Bouwen op maat is niet altijd nodig; soms is een nette Shiny- of Streamlit-uitbreiding genoeg en zeggen we dat ook.
Uw model draait al maanden in een Shiny-app, maar de gebruikers zijn niet meer alleen quants. Marketing, finance of bestuur willen er ook bij — en die haken af op de interface, de laadtijden of het ontbreken van mobiele toegang. U heeft productie-grade UX nodig zonder de R-stack op te geven.
DNB, AFM, ECB of een interne model-risk-afdeling wil aantoonbaar zien welke modelversie wanneer welke uitkomst gaf, en wie wat veranderde. Een notebook en een Excel-export volstaan daar niet. U heeft versie-beheer, change-logs en reproduceerbare runs nodig.
Wat met één analist op een lokale laptop werkte, schaalt niet door naar tien analisten die tegelijk scenario's draaien op enterprise-datasets. U wilt multi-user, gedeelde scenario-bibliotheken, en compute die meeschaalt — zonder dat elke quant zelf een eigen JupyterHub-instance beheert.
U bent een advies- of consultancy-bureau en uw model is de USP. Klanten betalen voor toegang. Dan heeft u een white-label-frontend, tenant-isolatie, een nette REST-API en een onboarding-flow nodig — geen losse Streamlit per klant.
Uw model haalt data uit een datawarehouse, schrijft resultaten terug in een transactiesysteem, en triggert workflows in uw CRM of risk-engine. Standaard-Shiny met een CSV-upload bouwt dat niet. U heeft een app nodig die als eerste-class burger in uw enterprise-architectuur leeft.
U wilt eindgebruikers laten praten met het model — uitleg vragen bij een uitkomst, anomalieën samengevat krijgen, alternatieve scenario's geneeren via natuurlijke taal. Dat vraagt om een LLM-laag bovenop uw econometrische kern, met retrieval-augmentation, prompt-engineering en kosten-monitoring per query.
Met OneDayBuild maken we je idee in één dag tastbaar voor €950, zodat je weet of verdere ontwikkeling de investering waard is. Besluit je door te gaan met de volledige bouw? Dan verrekenen we de kosten volledig.
Bekijk OneDayBuild →We kiezen de stack die bij uw model, uw team en uw governance past — niet andersom. Een korte oriëntatie op wat we typisch inzetten en wanneer een commercieel pakket eerlijker is.
Python met FastAPI of Django voor API-laag, R met Plumber voor R-native modellen, Julia met Genie als performance dat vraagt. Voor de modellen zelf: scikit-learn, statsmodels, PyTorch en TensorFlow in de Python-wereld; R-base met tidyverse en de mixed-modeling-pakketten in de R-wereld. Bayesiaanse stacks via Stan of PyMC, time-series met Prophet of statsmodels, scenario-simulaties soms in een eigen Monte-Carlo-engine.
React of Vue voor de productie-frontend, met Plotly, Bokeh of D3.js voor de modelvisualisaties — interactieve plots die scenario-output direct laten zien. Data in PostgreSQL voor relationele structuren, ClickHouse voor zware analytische werk, en Parquet of Arrow als uitwisselings-formaat met de modellen. Compute draait in AWS Batch, Lambda of Cloud Run, of bij langere modellen op JupyterHub of Posit Workbench naast de app.
R Shiny, Streamlit, Dash of Voilà voor interne tools waar geen multi-user-governance op zit. Tableau of Power BI als u alleen visualisaties wilt zonder modelling. Domino Data Lab of Databricks als u in een groot enterprise data-science platform zit en niet de UI-laag wilt vervangen. SAS, IBM SPSS, Stata of EViews voor klassiek-econometrische workflows. MATLAB voor engineering-quant. We zijn eerlijk wanneer een van die alternatieven beter past — uw budget en uw team zijn belangrijker dan onze omzet.
Een gesprek waarin we begrijpen welk model centraal staat, wie het gaat gebruiken, welke datastromen er in en uit gaan, en welke compliance-context speelt. Vaak laten we uw quants het model live demonstreren in hun huidige tooling — Shiny, een notebook of een SAS-script.
Workshop met uw team plus interviews met drie tot vijf eindgebruikers. Aan het eind: concrete scope, technologie-keuzes (FastAPI versus Plumber, React versus Vue, compute-backend), de eerste schermflow en een data-architectuur. Inclusief een keuze tussen build versus extend-Shiny waar dat eerlijker is.
Elke twee weken een werkende build die u en uw quants kunnen testen. Eindgebruikers ook. Het model draait in elke sprint mee, zodat u zeker weet dat de productie-output overeenkomt met de notebook-output — bit-voor-bit reproduceerbaar. De eerste tier staat na een paar sprints.
Gefaseerd uitrollen naar uw gebruikersbase, training-sessies, en doorlopend beheer voor security, model-drift-detectie en nieuwe modelversies. Uw quants kunnen daarna zelf modellen pushen via de pipeline; wij blijven achter de schermen voor de zware refactors.
Wat opdrachtgevers meestal willen weten voor we beginnen.
Een kennismaking van een half uur, vrijblijvend. We luisteren naar uw modellen, uw gebruikers en uw governance-context, stellen scherpe vragen, en geven richting waar u iets aan heeft — ook als die richting "blijf bij Shiny" is.
Appfront gebruikt cookies en vergelijkbare technieken voor een goede werking van de website, voor analyse en voor marketing. Je kiest zelf wat je toestaat. Lees meer in ons privacybeleid.
