We dropped the ads. Then we finished the list.

This is our largest release since the launch, and the first full one in four weeks. It removes ads from the plan, and it adds notifications, item assignment, reports, an Overview, export and a guided Setup. Most of what follows is about the decisions under those features, and about what we found when we ran them.

Why the Free plan has no ads

When we launched, our pricing said the Free plan would show ads. No ad slot ever went live in production. When we looked again in October, the ads had earned nothing. We had switched off one network because of its ad quality, we had no approval from another, and the next candidate sold only push notifications and popunders and asked for three months of traffic first. So we removed the plan: the ad code, the consent banner and the cookie choices that only the ads needed.

The Free plan’s limits did not change. It is still 1 portfolio, 1 Scrum Team, 1 project and 5 members. The difference is that the plan no longer needs ads to pay for them.

A permission that reached nothing

Building item assignment meant reading how team roles reach an item. Our design says a team role applies to that team’s sprints and to the items in them. The code did not do that, so a person whose only write permission was the Developer team role could not move a card on their own board. Our help page described this as a rule. Most people never saw it, because the default Member role already grants that permission.

Sprints had the same gap. A Scrum Master invited as a Member and holding the team’s Scrum Master role could not create, plan, start, end or close that team’s sprints. Both gaps refused too much, so neither exposed anything, and no test had failed. The tests checked the rule that the code had, not the rule the design described. Team roles now reach what the design says, and they reach no further: not the backlog, and not another team’s sprint.

Measure before you build the fix

Everyone knows how to make a long list scroll well: virtualize it. We measured first. A 1,000-item backlog on a slowed CPU at phone width took a median of 53 ms per frame, about 19 frames a second. A 50-item project on the same setup took 17 ms, so size was the cause. But size was not the cause in the way we expected.

There were two causes. The button that follows your scroll position updated its state on every frame, even when it had not moved, and each update rendered every card again. And each frame laid out and painted about 9,800 nodes, most of them off the screen. We moved the button’s state into its own component, and we gave each row the browser’s own content-visibility: auto. The median frame is now 17 ms. No JavaScript virtualization was needed, so find-in-page, keyboard focus and drag-and-drop all work as they did.

Reading a spreadsheet ourselves

Import now reads .xlsx as well as .csv. Our plan named a popular library. A check before the build changed that plan. The library’s last release was three years old, it would have added 193 packages to about 100, and its reader did not limit its memory use. That is the same class of defect we fixed in our CSV parser in October.

So we wrote a small reader that uses Node’s own inflate. It unpacks only the parts of the file it needs, under one budget for the whole workbook, and its XML scanner only moves forward. Writing it ourselves also made its defects ours. A review before this release found small files that still cost the reader too much memory. We added limits for one cell and for a whole sheet, and those files now get a plain refusal.

Setup reads what exists

A new organization now opens on Setup, a list of eight steps from your first settings to your first sprint. We did not build a practice project. On the Free plan it would use your only project, and you would have to build the real one anyway. The steps link to the real screens, and the public demo is there if you want to see a finished example.

Seven of the steps read the rows that exist on every load. The first asks only whether the settings were ever saved, because a default name looks the same as a chosen one, and that one fact comes from the activity log. We rejected recording each step as it happened, and we rejected building the list from the log, because both can disagree with what is really there. A person who joins from now on meets a welcome page instead, which shows their own team, sprint, assigned work and next Scrum Event, and which never names a project that is hidden from them.

What running it found

We ran the full sprint cycle in Chrome emulating a phone, through the screens only, with real touch events. That found a gap we should have seen sooner: no screen could start a Retrospective. A Sprint Review existed only if the product had booked it. Every test passed, because no test had asked. Both screens now offer to start one.

The same habit found a cancelled sprint that kept its dates. New sprint then offered those dates and refused them. It also found an item panel that conflicted with itself when two saves ran close together. A unit test rarely finds this kind of defect. You find it by using the product. We also fixed a limit that our help had described for some time: an invited person who continues with a sign-in provider now comes back to the invitation.

Two scans on release day

On the morning of this release we ran a full security scan over the code and over how the features work together. It confirmed 38 items, some of them the same defect seen from two sides. Some were in new code that had never reached production. Others were not, and those are the reason this release also fixes things in the site you already use.

Then we fixed them and scanned again, because about 45 commits had landed since the first scan. The second scan confirmed 16 more. The one we think about most is one we caused that afternoon: a fix for a formula guard in CSV files was itself far too slow on a crafted file. The second scan measured it, and it never reached production. A fix is new code, and it gets the same suspicion as any other new code.

The function test found something a scan did not. One test client on our development site filled its database connections, and exports began to fail. Production showed no such error, but it had the same settings, so each server now keeps a small, fixed number of connections.

The final code passed 4,038 automated tests and 1,326 of 1,329 checks against the hosted development site, through the API and in a real browser. The other three expected an older answer to a request from another site, and we changed that answer on purpose.

SimpleScrumTools is free for teams of up to 5 members, with no card required and no ads. Create a free account.