suruosh
ONEbasket · May to October 2026

ONEbasket: from first app to beta

Five months ago, ONEbasket® was a Chrome extension and a website. Today it's an installable app, an Insight Board and a beta. I worked on both stretches. At Hyper Island I led the team that built the first app. Then I took the seven-week sprint end to end: the beta, the interface and visual language, and the measurement that proves it works.

Case study6 min readonebasket.ai
The ONEbasket landing page from top to bottom, from the “Give your finds a home” hero to Baski and the questions at the end.

01 / 07The conversion-focused landing, with instant saving from the hero and Baski further down.

The Vision page from top to bottom: Today’s edit, the creator economy, business, and the agents.

02 / 07The Vision page, a first look at where ONEbasket is going.

The ONEbasket app home: Add New, My Wishlists and Magic Save, above a row of recent wishlists.The ONEbasket app home: Add New, My Wishlists and Magic Save, above a row of recent wishlists.

03 / 07Home, in the redesigned app. It follows this page’s theme.

The Wishlists screen: a grid of named baskets, each with its item count, shop logos and product photos.

04 / 07Wishlists, connected to real baskets.

The Add New window with an oil-green Zalando jumper read from its link, a carousel of wishlists to save it to, and a Save button.

05 / 07The Add window, inside the app.

The Board overview: counts of baskets, saved products, price drops and visitors, then recent price changes and every basket.

06 / 07The Insight Board: price history and basket visits (with consent).

The Board’s Agentic page, marked coming soon, with example tasks for shoppers, curators and merchants.

07 / 07A coming-soon page on the Board.

Overview

ONEbasket is Marie Bjerkevall's Swedish startup: one basket for everything you want to buy, across every store, with price tracking.

Client
ONEbasket®, founded by Marie Bjerkevall
Role
Team lead, Hyper Island Team 3; end to end on a seven-week sprint, from code to interface and visual language
Stack
Next.js and React PWA on Vercel; Express API with PostgreSQL; Plasmo Chrome extension; Sentry, Firecrawl, Gemini
Delivered
All eight agreed sprint items, 61 merged pull requests, 25 production deploys, 3 Chrome Web Store releases
From first app to betaONEbasket milestones, May to October 2026
  1. Team 3 builds the appMay 1 to May 13
  2. Stakeholder demoMay 14
  3. Codebase reviewJun 9
  4. Sprint plannedAug 12
  5. Sprint, 7 weeksAug 18 to Oct 2
  6. Backend releasesSep 8 to Sep 30
  7. App and Board liveOct 2

The work came in two parts: a 13-day Hyper Island project that created the app, and a seven-week sprint that brought the product to its beta.

Background

I met ONEbasket during Hyper Island's FED program, in the Working with Industry course, where teams work on real companies' products. ONEbasket took on two teams: mine, Team 3, and our sister team, Team 6.

At the time ONEbasket was a Chrome extension and a website where shoppers kept their finds, wishlists and shared baskets. Behind it sat an Express API and a product reader that used a page's structured data first and AI as a fallback.

The next step was an installable app, something a shopper could carry on their phone. Team 3's brief was to build it, while Team 6 worked on the website.

Hyper Island: building the first app

In 13 days Team 3 turned the website into an installable app at /app. I led the team of five through three phases, brought everyone's work together at the end of each one, and built the third, Magic Save.

Phase What it delivered
1. Foundation Installable /app shell, service worker, iOS Add to Home Screen, mobile header and footer
2. Content Wishlist grid with paging, wishlist and product pages, profile, the Add product window
3. Magic Save Save from outside the app: the phone's share sheet, a pasted link, a home-screen entry, offline start

We built the foundation together, and Noorae, Ebrima, Sandy and Irem built the Content phase and the integration branch. In the same weeks Team 6 worked on the website.

We then presented to the stakeholders. Magic Save could take a shared link all the way to a real product read, while the app's browse screens still used demo data, as planned for a first version. Connecting them to live data later became one of the sprint items.

Continuing after the course

When the course ended, Marie invited me to keep working with her. We agreed on a seven-week sprint built around the priorities she set for the beta: seven items, with an eighth added in the first week.

Before writing a line of code in the sprint, I studied everything: the architecture, what could break, and every direction the product could take. Each item was planned against the code: what already existed, what needed to change, and in what order backend changes could be released safely. I kept checking the plan as the sprint moved, so each release started from an up-to-date picture.

What we delivered

Over the seven weeks, all eight items went live. Marie set the direction and the priorities; I took the sprint end to end, from the code to the interface and visual language, the releases and the measurement.

Item What shipped Result
1. Security A security review and hardening pass across the API and the extension Tested before each release
2. Monitoring Error reporting, uptime alerts, and automated checks that run before every deploy Alerts verified in production
3. Instant save Saves confirm at once while the product page is read in the background, with Try again if a read fails Saves confirmed in under 200 ms
4. Extension A rebuilt extension, versions 1.1.0 to 1.1.3: a redesign, right-click save and instant save 3 Chrome Web Store releases, each approved
5. Swedish shops A shop-by-shop test harness, support for Swedish price formats, and a fallback for pages that are hard to read 20 of 20 major shops saving correctly
6. The app /app connected to real baskets, with offline support Live in the beta
7. Polish pass A conversion-focused landing with instant saving from the hero, Baski the AI guide, sign-in inside the app, the app redesigned from the ground up, the Insight Board, and an editorial feed Shipped at the end of the sprint
8. Price history A weekly re-check of saved prices that builds each product's price history Running every week

Baski answers in Swedish or English and walks visitors into the app. The Insight Board brings together price history, basket visits (with consent), settings and the product vision. The editorial feed is built around real shared baskets, where curation is the point. The website, the app and the Board now share one visual language.

Underneath: security hardening, error monitoring, a deploy gate, a rebuilt extension with 3 Chrome Web Store releases, and 25 production deploys. Each one shipped as a step that could be undone, and each was monitored live.

Built to win, not just to work

Why study everything before writing code? Because I don't build products just to make them work. I build them to win. Once you think that way, every decision changes. You look beyond what needs to ship today, understand the whole system, and keep the product ready for every path it can take.

That shaped the decisions behind the sprint:

  • Release in small, reversible steps. Website, extension and tooling changes merged first. Backend changes waited on their own branch and went out one at a time, each followed by a 30-minute watch and a check that the new version was really serving.
  • Protect what users already have. Instant save shipped as opt-in, because switching it on for everyone would have affected extensions already installed. Extension 1.1.2 worked with both the old and the new API.
  • Use a specialist where it fits. For shop pages that are hard to read automatically, I chose Firecrawl, a purpose-built page-fetching service, as the fallback.
  • Leave a price empty rather than guess. When the reader is unsure of a price, it stores nothing. A wrong price is worse than a missing one.
  • Measure instead of assuming. A page-size limit that looked generous turned out too small for a real Åhléns product page, so the limit was raised to fit what the shops actually serve.
  • Fixes before polish. The design pass came after the functional work, so no screen had to be redone twice.
  • Keep every path open. The directions we didn't build yet are designed in as foundations, so ONEbasket can grow into them without a rewrite.

The last release followed the same idea: the app and the Board went out as nine pull requests in a row, each one checked live before the next.

Outcome

By the end of the sprint all eight items were live, and ONEbasket is now in beta.

What I'm taking with me

  • Understanding a system before changing it pays back. Studying the code before planning made the sprint calmer and the plan more reliable.
  • Good planning and small, reversible releases keep chaos out. Being able to undo any step mattered more than speed.
  • Clear priorities keep a sprint focused. Marie's priorities gave the work a clear finish line, and a short weekly written note kept us aligned along the way.

Thanks

Thank you Noorae, Ebrima, Sandy and Irem for building the first app with me, and Yordanos, Emma, Patricia and Siri of Team 6 for your work on the website.

Marie, thank you for the trust, a vision worth building for, and clear direction throughout. This sprint is shipped, and there's more to come.