Organic Food Boutique Store
A bootcamp storefront built by nine people at once, where the useful question is not what the team shipped but which part of it I wrote — and what choosing the piece that depended on everyone else cost me at the end.
- Role
- Cart logic, hero band, scrum master
- Year
- 2023
- Stack
- HTML · CSS · JavaScript · Vite
Context
- 9
- people committing to one repository
- 58
- pull requests, one branch per piece
Organic Food Boutique Store was a bootcamp team project: a storefront for a food subscription service, built against a REST API the course supplied. Nine of us committed to one repository, and it belongs to a teammate rather than to me — which is why this case study leads with a drawing of which regions of the site I wrote instead of a screenshot of the whole of it.
The work was split by component. Each person took a piece of the page — header, hero, filters, product list, popular products, discounted products, the modals, the cart — built it on its own branch and opened a pull request into main; fifty-eight of them went in that way, and the titles name who did which. I was scrum master for the sprint: I ran the stand-up every evening and kept the task board.
The deadline was one week. It became ten days.
Constraints
None of these came from a client. They are the ordinary conditions of building one page of a site while eight other people build the rest of it, and each of them decided something about what I could finish and when.
- The repository is not mine
- It lives under a teammate’s account. Nothing about my contribution is visible from outside it — not on my profile, not in a repository I can link to as my own — and anyone assessing this work arrives with exactly one question and no convenient way to answer it. That is what the figure below is for, and why this project has a scope line on its card when the others do not.
- Everything I built stood on somebody else’s code
- The cart reads through the API service and the storage wrapper, both written by the repository owner before I started. It renders into markup a teammate wrote and styled. The number it produces is displayed by a header two other people owned. I wrote the middle of that chain and neither end of it.
- One week, then ten days
- The deadline moved once, and in our favour. Worth saying plainly because it rules out the obvious explanation for how the sprint ended: the schedule was not the thing that went wrong.
Key decisions
Two of these I made deliberately. The third thing I did was also a decision, but I did not recognise it as one at the time, so it is in the last section instead of this one.
- Take the cart, because it used the most of what we had been taught
- It exercised more of the course than any other piece on the board — state, storage, rendering from data, talking to the API — and it carried real responsibility: it is the page where a wrong number is a wrong order rather than a cosmetic defect. It also depended on more of other people’s work than anything else available, and I treated that as an argument for taking it.
- Render the rows rather than ship them
- The cart page arrived as static markup with example items written into the HTML. I removed them and had the JavaScript build the rows from stored state instead, so the page shows what is in the cart rather than what happened to be in it when someone wrote the markup. It is one commit, and it is the commit that turned a layout into a page.
- Take corrections instead of claiming a fourth piece
- Once the hero band was merged I picked up work on two sections other people owned — a fix on the popular-products list and an animation on the discounted-products one — rather than starting something new of my own. On a build this short, the useful work at that point is the work already in flight.
Deep dive
The cart is the junction of this site. Everything else on the page is a leaf — a filter, a card, a modal — and the cart is the one place where the API, the stored state, someone else’s markup and someone else’s header counter all have to agree with each other at the same moment.
What it reads. Products and quantities come through the API service and the storage wrapper, both of which existed before I opened the file. I did not write the transport and I did not write the persistence. I wrote the part in between, which turns what is stored into what is on the screen.
What it writes. A quantity change, a removal and an emptied cart all go back to storage, and both the order total and the header badge read from there. Two of the three things reading that number belonged to other people, which is why the count is the value on this page most exposed to a disagreement between authors.
What it renders. Rows are built from stored items rather than written into the document, so changing a quantity re-renders the row and the totals from one source instead of updating three places and hoping they match.
The hero band, on the other sheet. A heading, a subtitle and the hero image at the top of the catalogue, with one word of the heading cycling colour on a loop. It is the only thing I wrote anywhere on this site that a reviewer can watch working without opening a file.
Where my work stopped. The cart went in through one pull request near the end of the sprint, and two commits by the repository owner followed the same afternoon — one of them fixing the cart’s update on a quantity change. The commit log is the honest record of the boundary, and a case study that claimed the page outright would be contradicted by it in about a minute.
Which part was mine
A team project, so the only useful question is which parts I wrote. Lit regions my code drew. Boxed but dim: somebody else’s element, with a number my code writes into it — the note says which number. Everything else dimmed and unboxed is not mine in any sense. Each note names something checkable against the repository.
- hero.html4 commits
- rotateColor4s infinite
- hero.css6 commits
- their headerthe count is cart.js
- cart.js4 commits · builds the rows
- her order panelthe sum is cart.js
- JS-Cart-Pagebranch · the quantity control
- Scrum master · daily stand-up · task board
- 22 Nov – 1 Dec 2023 · 15 commits
Results
The site is live and the repository is public. What I wrote is drawn above, region by region, with a file, a commit count or a branch on each note — so the whole claim can be checked against the commit history by anyone who wants to spend a minute on it.
There is no outcome metric here, and there is not going to be one. A bootcamp team project has no client, no traffic and no Search Console property: nobody was ever going to shop in this store, nothing was ever going to convert, and nothing was measured after the presentation. The obdukcje case study reports positions and impressions because a real site produced them and I can re-check them monthly. This one reports what shipped, because that is the entirety of what exists.
What is checkable, for anyone inclined: the branch the cart work was done on, the pull request that merged it, the commits on every file named in the figure, and the pull-request titles, which name a person for each piece of the site.
The last thing to happen on the project was mine and it was small — a style fix on the cart form, opened after the sprint had ended and merged more than two weeks later.
What I'd do differently
I chose the cart because it depended on more of other people’s work than anything else on the board. That dependency is what left me waiting at the end.
The building itself went fine. The last days did not: we had a presentation to prepare, and my part could not be finished until the parts it consumes were finished. I was the scrum master. I had the board in front of me the whole time, I could see every card on it, and I still ended up waiting.
The lesson is not that I picked the wrong piece. It is that I picked the piece with the most dependencies while holding the one role that could have sequenced them, and carried those two facts around as though they had nothing to do with each other.
The concrete version, for next time: the parts my page consumed were an interface before they were code, and I could have written that interface down on day one and built the cart against a stub of it. Then the last days are an integration, which is short, and not a wait, which is open-ended.