project
service
website
job
Web development
to banking standards
to banking standards
IVIS MEDIA Berlin delivered the frontend engineering for VR-KARRIERE, the recruiting platform of Germany's cooperative financial group Volksbanken Raiffeisenbanken: a component-based frontend for marketing pages, job-ad booking and a self-service portal, wired to a Kotlin backend. The design came from the client – the code came from us: structured, accessible, documented and handed over to the in-house teams in full after sign-off. A reference project for web development for banks, meeting banking requirements for quality, security and maintainability.
VR-KARRIERE (vr-karriere.de) is the recruiting and job-ad platform of the cooperative financial group Volksbanken Raiffeisenbanken. Employers book ad packages, publish job ads and manage their reach in one place; candidates search roles by keyword, postcode and radius. IVIS MEDIA Berlin programmed the entire frontend of this platform.
Frontend engineering – not design. Brand and visual design stayed with the client, the Kotlin backend with their IT. We turned the design files into a production-ready frontend, connected it to the REST interfaces, tested it against a financial institution's acceptance criteria and handed the frontend over in full.
Vue.js, JavaScript, TypeScript, HTML5, CSS3/SCSS, design tokens, component architecture, REST APIs, Kotlin backend (client side), Git, CI/CD, WCAG 2.1 AA
Live platform with public product and marketing pages, job search with radius filter, ad packages in direct comparison, an end-to-end booking flow and a self-service portal for employers with a central dashboard: manage job ads, buy ad packages, maintain company data, pull reports and review past bookings. Responsive from phone to desktop, accessible to WCAG 2.1 AA, documented and handed to the in-house development teams after sign-off.
Web development for a consistent brand experience
For VR-KARRIERE we turned the supplied designs into a frontend – pixel-accurate, but not blindly rebuilt. Recurring patterns became a component library with clear props, slots and states: every element exists once in the code instead of five times across five templates. Our glossary explains what frontend development involves in detail.
Typography, spacing, colours and breakpoints live as design tokens in central SCSS rather than scattered across individual views. A brand change stays a tweak instead of becoming a project – the precondition for in-house teams to keep developing the frontend after handover. The UI implementation followed the client's specification throughout.
Frontend development for portal and booking flow
The frontend covers two worlds: public pages where employers compare ad formats, reach and packages from Basic to Premium Plus – and a protected self-service portal behind the login. There, HR teams manage job ads, buy ad packages, maintain company data, pull reports and review past bookings.
The booking flow from package comparison to confirmation is one continuous journey with validated forms, clear error states and transparent intermediate steps. Job search filters by keyword, postcode and radius. All data arrives through REST APIs from the Kotlin backend: the frontend holds no source of truth of its own, it mirrors the server.
Dashboard: a self-service portal for staff and clients
After login, HR staff land on a dashboard that gathers every key function in one place: view job ads, buy ad packages, manage the company, pull reports, review past bookings, change personal details. Six tiles instead of nested menus – the daily task sits one click away, not several menu levels down. As a client portal, the dashboard is where recruiting budget actually gets managed.
Personal account and company account stay separate, so several people at one bank work on the same company profile without overwriting each other's master data. Reports and booking history make spent budget traceable for managers, and the help button sits in the header rather than the footer. Each tile loads its data over REST from the Kotlin backend – with its own loading and error states, so a slow request never looks like an empty account. Tablet and desktop share one layout and the same component library as the public pages.
An accessible website to banking standards
A financial institution reviews differently than a start-up. Accessibility to WCAG 2.1 AA was an acceptance criterion, not a nice-to-have: semantic HTML, full keyboard operation, visible focus states, verified contrast and ARIA roles exactly where native elements fall short. Our page on accessible websites shows what that involves.
Add to that code reviews, linting and build gates in CI, a documented component library and a clean handover state – after sign-off the frontend passed entirely into the hands of in-house development. This is the way of working IVIS MEDIA Berlin brings to web development and software consulting for regulated industries.
