Splync v1.9 kan aangepaste verdeelsleutels instellen voor elke uitgave

Ongeveer anderhalve maand na de release van Splync v1.5 — de update die eindelijk aangepaste verdeelsleutels per project en per categorie mogelijk maakte — kwam er een nieuwe golf van feedback binnen. De v1.5-update vereiste grote serveraanpassingen, dus destijds dacht ik dat de nauwkeurigheid wel “goed genoeg” was voor de meeste gevallen. Toen stelden enkele nieuwe gebruikers een eenvoudige, heel redelijke vraag: “Kunnen we aangepaste verdeelsleutels per individuele uitgave instellen?” Hun reisproject had momenten waarop slechts twee leden een specifieke kostenpost moesten delen, en andere momenten waarop alle drie iets wilden delen. Onder Splync v1.8 was het antwoord helaas nee. Ik legde uit dat ze extra categorieën konden maken met aangepaste verhoudingen voor die specifieke gevallen — een tussenoplossing, geen echte oplossing.

Het voelde een beetje overweldigend om te herinneren hoeveel werk er in v1.5 zat. Eerst moesten projecten hun eigen verdeelsleutels hebben. Daarna hadden categorieën ook hun eigen aangepaste verhoudingen nodig. Op dat moment dacht ik dat ik de hele boom had behandeld — elke vrucht van elke tak verzameld. Maar werken aan verhoudingen per uitgave was anders. Het voelde alsof er elke keer dat ik een vrucht plukte, een nieuwe boom ontstond op die plek. Niet een oneindig fractaal bos, maar een duidelijke tweelaagse structuur: één laag die de volgende voortbrengt. In de logica van v1.5 erfde een uitgave eerst de verhouding van het project. Als de categorie aangepaste verhoudingen had, zouden die de projectwaarden overschrijven. Dus toen ik verhoudingen per uitgave toevoegde, probeerde ik een andere overschrijving bovenop die overschrijving toe te voegen. De structuur werd een trap van overschrijvingen — technisch correct, maar mentaal onoverzichtelijk. Het was moeilijk om nog een laag van pleisterlogica te rechtvaardigen.

De doorbraak kwam uiteindelijk door de structuur om te draaien. In plaats van “project → categorie → uitgave” en elke laag met de volgende te overschrijven, waarom niet in de tegenovergestelde richting denken? Per-uitgave aandelen → per-categorie aandelen → per-project aandelen. Die volgorde weerspiegelt hoe mensen echt denken: als een specifieke uitgave zijn eigen regels heeft, moet hij die gewoon volgen. Zo niet, dan is het patroon van de categorie logisch. Als dat ook niet werkt, val dan terug op de standaard van het project. Geen trap van overschrijvingen meer — gewoon een duidelijke hiërarchie van prioriteit. Toen ik de structuur zo zag, verdween de mist van het pseudo-fractaal bos onmiddellijk. Het implementatiepad werd duidelijk: “Elke uitgave wordt gecontroleerd op aangepaste aandelen per uitgave. Als die er zijn, gebruik ze. Zo niet, controleer dan de aandelen per categorie. Zo niet, gebruik de projectstandaard.”

De nieuwe logica voelde eenvoudig, voorspelbaar en wiskundig kloppend. Om dit prioriteitssysteem te ondersteunen, hebben we een speciale MariaDB-tabel toegevoegd voor splitsingen per uitgave, een soort spiegelbeeld van de tabel voor splitsingen per categorie. De detailtabel voor uitgaven moest ook worden uitgebreid, net als de detailtabel voor categorieën in v1.5. Zodra het onderliggende “tweelaags” ontwerp duidelijk werd, was de rest gewoon zorgvuldig coderen — zowel in de app als op de server. Toch voelde het pad soms riskant, alsof je door een donker bos zonder kaart loopt. Ik wilde mijn hoofd leegmaken en stapte naar buiten. De lucht was scherp en schoon. Terwijl ik door mijn buurt liep, zag ik de Mt. Fuji in de verte oprijzen, kristalblauw onder een perfect blauwe lucht. Het was bijna 100 km verderop, maar het leek dichtbij genoeg om aan te raken. Het moment voelde als een herinnering: zelfs als ik denk dat ik in een bos wandel, loop ik eigenlijk onder de open hemel.

Splync v1.9 is geboren uit dat moment van helderheid. Ik ging naar huis, zette de nieuwe eindpunten in elkaar, bereidde de nieuwe serverlogica voor, organiseerde de gerelateerde interfaces, diende v1.9 in bij Apple en viel uiteindelijk in slaap. De beoordeling was eerder klaar dan normaal. Toen ik wakker werd, was Splync v1.9 al goedgekeurd en automatisch uitgebracht in de App Store. Vanaf deze versie wordt het splitsen veel flexibeler. Als je met John en Kate reist, kun je basisuitgaven gelijkmatig over jullie drieën verdelen. Maar voor eten kun je schakelen naar een “25% : 50% : 25%” splitsing omdat John meestal twee keer zoveel eet. En als John een diner overslaat — bijvoorbeeld in een oesterrestaurant — kun je die specifieke maaltijd instellen op “50% : 0% : 50%” zodat hij niet betaalt voor wat hij niet heeft gegeten. Met v1.9 ondersteunt Splync nu verhoudingen per project, per categorie en per uitgave in een verenigde logica. De fundamenten zijn stabiel en wiskundig kloppend. De volgende uitdaging is de interface: sommige andere splitsingsapps bieden soepelere, stijlvollere manieren om die verhoudingen aan te passen. Splync heeft nu de backendkracht om zulke verbeteringen te ondersteunen. We zullen eraan werken, stap voor stap.