Software laten maken in Utrecht.

Utrecht is geen kopie van Amsterdam of Rotterdam. De stad draait om kennis, regels en publieke verantwoording: de Rabobank-HQ aan de Croeselaan, de ASR-toren aan de Archimedeslaan, het UMC Utrecht en het Utrecht Science Park, de campussen van de Universiteit Utrecht (UU) en Hogeschool Utrecht (HU), het Stadskantoor van de gemeente Utrecht naast Hoog Catharijne, en een groeiende scale-up- en startup-scene bij Dutch Game Garden, ITSU Utrecht Startup Hub en Beeyond. Daar hoort een softwarepartner bij die weet hoe banking-toezicht, NEN 7510, Common Ground en SURFconext in de praktijk werken — niet één die dat in een whitepaper heeft gelezen.

Bij Appfront bouwen we software die in productie moet draaien onder de ogen van DNB, AFM, IGJ, een gemeente-CISO of een interne audit-functie van Rabobank of ASR. Voor Utrechtse opdrachtgevers vertaalt dat zich naar concrete keuzes: EU-residency op data, helder ingerichte audit-trails, sterke authenticatie, integratie op bestaande core-systemen, en aanbestedings-vriendelijke contracten zonder lock-in op één leverancier. Voor de bredere praktijk — onafhankelijk van locatie — zie software laten maken.

Werkt u óók met een mobiele app of een webapp-vraagstuk? Onze zusterpagina's app-ontwikkelaar Utrecht en webapp-ontwikkelaar Utrecht beschrijven die kant van het werk. Voor veel Utrechtse opdrachtgevers bouwen we parallel aan een desktop-webapp, een mobile-companion én een back-office-platform.

Software in productie is meer dan een nette UI. We bouwen voor opdrachtgevers met strikte proxy-instellingen op een Rabobank-werkplek, een Citrix-omgeving op een UMC-werkstation of een gemeente-laptop op een ouder OS. Front-end: React, Vue of Svelte, met server-side rendering waar SEO of first-paint dat eist. Backend: Node, Python of .NET, afhankelijk van uw bestaande stack.

Voor integraties bouwen we API's bovenop uw bestaande systemen: core-banking, polis-administratie, EPD/HIS, ERP, en identity-providers als Azure AD, ADFS, SURFconext of een eigen OIDC-stack. We kiezen voor open standaarden (OAuth 2 met PKCE, OpenID Connect, SAML, eIDAS waar relevant) in plaats van eigen oplossingen. Voor zorgcontext betekent dat tegenwoordig vaak een koppeling op Nictiz-standaarden of HL7 FHIR; voor publieke context vaak een koppeling op het Common Ground-stelsel via Open Zaak of een vergelijkbare service-laag.

Alles wat in productie gaat is voorzien van observability: error-reporting, performance-monitoring, audit-logging en alerting op de backend — in een banking- of zorg-context het verschil tussen vertrouwen en frustratie. AVG en EU-residency standaard met EU-datacenters van AWS, Azure of GCP, plus — voor banking-opdrachtgevers — externe pentest-rondes voor go-live.

Een traject start met een kennismaking: een vrijblijvend gesprek waarin we doornemen welk probleem u wil aanpakken, welke systemen er staan, en wat directie, IT, gebruikers en — afhankelijk van de sector — compliance, security of audit ervan verwachten. Vaak komt er uit: dit kan ook als feature in een bestaand pakket, hier is een SaaS-product goedkoper, of dit is precies de use-case waar eigen software voor uw Rabobank-, ASR-, UMC- of gemeente-omgeving waarde toevoegt.

Daarna een discovery: een korte fase waarin we de oplossing op architectuur- en interactie-niveau uitwerken — welke front-end, welke backend, welke integraties met core-systemen, welke identity-provider (Azure AD, SURFconext, een eigen OIDC), welke audit-eisen. Resultaat: een concreet plan met scope en budget — bij gemeente Utrecht en UU vaak ook geschikt om in een aanbestedings- of inkoopkader te brengen.

Dan volgt de bouw in sprints. Aan het eind van elke sprint draait er iets werkends in een staging-omgeving die we vooraf met uw security-team hebben afgestemd. Na go-live volgt beheer: security-patches, performance-tuning en audit-rapportages. We bieden doorlopende ondersteuning of dragen het netjes over aan uw eigen team — afhankelijk van wat past.