Arctic Adventures runs hundreds of tours across Iceland's glaciers, caves and rivers. Moberg is building the user portal and back office that let the company run them — starting from a two-day workshop and now well past MVP.
Arctic Adventures is one of Iceland's largest adventure tour operators — a company that started as a river rafting outfit in 1983 and now runs 200+ small-group day and multi-day tours across glaciers, ice caves and volcanic landscapes, trusted by over a million travellers a year. Operating at that scale means the software behind the tours matters as much as the guides in front of them.
Moberg's engagement covers the user portal and the back office — the systems where customers and staff meet the operation. The work began not with code but with two days of discovery workshops to pin down the feature set, followed by software architecture and then development. The MVP is finished; larger features are now in development, and a mobile app sits on the horizon as a possible next step.
The project started deliberately slowly. Two days of discovery workshops with Arctic Adventures produced a defined feature set before anyone opened an editor — which sounds obvious and is routinely skipped. The workshops turned a broad ambition ("a portal and back office") into a scoped list of what the first version had to do, what could wait, and what would probably never earn its place.
From that feature set, Moberg designed the software architecture and then built it: a .NET backend carrying the business logic and a React frontend for the portal and back-office interfaces. The split is conventional on purpose — a tour operator's competitive edge is in its tours, not in exotic infrastructure, so the stack is chosen for hiring, maintenance and longevity.
With the MVP shipped, the engagement has moved into its second phase: developing the larger features the workshops identified but deliberately deferred. The architecture was designed with those features in mind, so extending the system is a matter of building, not rebuilding. A mobile app is a possible next step — the backend it would need already exists.
A discovery workshop only works if it ends in decisions. Compressing a full feature set — and the harder list of what not to build — into two days demands discipline from both sides of the table.
Shipping a minimum version fast is easy; shipping one whose architecture already anticipates the larger features behind it is the actual job. The second phase is now proving out those early decisions.
Arctic Adventures runs tours year-round at national scale. The portal and back office serve a real operation with real customers, which sets the bar for reliability from the first release, not the last.
The two-day discovery investment paid for itself before development started: a shared, written understanding of the feature set meant architecture and build proceeded without the mid-project scope renegotiations that quietly sink fixed ambitions. Arctic Adventures got an MVP on a foundation designed for what comes after it, not just for the demo.
The phased shape of the engagement also keeps the risk profile sane. The company saw a working system early, and each larger feature now lands on a platform already in use — feedback from reality, not from a specification document. If the mobile app happens, it inherits a backend that was built expecting the question.
The business logic behind the portal and back office — chosen for longevity and maintainability.
The user portal and back-office interfaces customers and staff actually touch.