EXPENSE TRACKER (TP)
EXPENSE TRACKER (TP)
The trackpie app lets two or more people spend from one monthly pot and always know what's left.
Any member logs an expense in seconds: amount, category, payment method, optional note and the household's remaining balance updates immediately. Author and date are captured automatically. Spending resolves into three views that answer the three questions households actually argue about: how much is left, where it went, and who spent it.
Members choose one of two budget models at setup: Automatic, a recurring amount that reinstates on the 1st indefinitely, or Manual, a month-scoped amount they control directly. Every month is archived, so resetting the budget never erases the record.
Built solo, end to end: product definition, interaction design, a documented design system, and front-end implementation using AI-assisted development.
BUSINESS CHALLENGE
BUSINESS CHALLENGE
Households that share money rarely share visibility.
Receipts in a drawer, a cash envelope, a spreadsheet one person maintains, every low-tech method fails the same way. The number that actually governs behaviour, what's left this month, is only accurate to whoever last did the math. Everyone else spends blind, and reconciliation becomes a month-end conversation nobody wants to have.
The commercial market doesn't close this gap. Mainstream personal finance apps are built around the individual: bank sync, net worth, long-horizon goals, retrospective reporting. They tell you what you spent after you spent it. Very few are built for a small group spending against one shared, variable pot, in the moment, from different wallets.
Households that share money rarely share visibility.
Receipts in a drawer, a cash envelope, a spreadsheet one person maintains, every low-tech method fails the same way. The number that actually governs behaviour, what's left this month, is only accurate to whoever last did the math. Everyone else spends blind, and reconciliation becomes a month-end conversation nobody wants to have.
The commercial market doesn't close this gap. Mainstream personal finance apps are built around the individual: bank sync, net worth, long-horizon goals, retrospective reporting. They tell you what you spent after you spent it. Very few are built for a small group spending against one shared, variable pot, in the moment, from different wallets.
BUSINESS CHALLENGE
Households that share money rarely share visibility.
Receipts in a drawer, a cash envelope, a spreadsheet one person maintains, every low-tech method fails the same way. The number that actually governs behaviour, what's left this month, is only accurate to whoever last did the math. Everyone else spends blind, and reconciliation becomes a month-end conversation nobody wants to have.
The commercial market doesn't close this gap. Mainstream personal finance apps are built around the individual: bank sync, net worth, long-horizon goals, retrospective reporting. They tell you what you spent after you spent it. Very few are built for a small group spending against one shared, variable pot, in the moment, from different wallets.
USER RESEARCH & INSIGHTS
USER RESEARCH & INSIGHTS
The product was designed against a household challenge, then validated by running my own home's finances on it through a complete monthly cycle, dozens of transactions logged by two people from different wallets in real conditions.
People don't want a spending report. They want a remaining balance. Retrospective summaries arrive after the decision that mattered. The question being asked in the store aisle is "can we?" and only a live figure answers it.
A dollar amount isn't glanceable; a proportion is. "$X remaining" means nothing without knowing the denominator and the date. "46% remaining" is immediately interpretable. This became the single most consequential interface decision in the product.
Attribution is emotionally loaded. Manual tracking forces someone into the accountant role, and that person becomes the one asking where the money went. When the system captures who logged what automatically, the record stops being an accusation and becomes a fact.
Households aren't uniformly stable. Some want to set a number once and stop thinking about it. Others have variable income and need to move it mid-month. Forcing either group into the other's model breaks the habit within weeks.
Logging has a friction ceiling. An expense entry competes with walking out of a store. Anything past a handful of fields doesn't get logged, and an unlogged expense corrupts the only number the product exists to protect.
The product was designed against a household challenge, then validated by running my own home's finances on it through a complete monthly cycle, dozens of transactions logged by two people from different wallets in real conditions.
People don't want a spending report. They want a remaining balance. Retrospective summaries arrive after the decision that mattered. The question being asked in the store aisle is "can we?" and only a live figure answers it.
A dollar amount isn't glanceable; a proportion is. "$X remaining" means nothing without knowing the denominator and the date. "46% remaining" is immediately interpretable. This became the single most consequential interface decision in the product.
Attribution is emotionally loaded. Manual tracking forces someone into the accountant role, and that person becomes the one asking where the money went. When the system captures who logged what automatically, the record stops being an accusation and becomes a fact.
Households aren't uniformly stable. Some want to set a number once and stop thinking about it. Others have variable income and need to move it mid-month. Forcing either group into the other's model breaks the habit within weeks.
Logging has a friction ceiling. An expense entry competes with walking out of a store. Anything past a handful of fields doesn't get logged, and an unlogged expense corrupts the only number the product exists to protect.
USER RESEARCH & INSIGHTS
The product was designed against a household challenge, then validated by running my own home's finances on it through a complete monthly cycle, dozens of transactions logged by two people from different wallets in real conditions.
People don't want a spending report. They want a remaining balance. Retrospective summaries arrive after the decision that mattered. The question being asked in the store aisle is "can we?" and only a live figure answers it.
A dollar amount isn't glanceable; a proportion is. "$X remaining" means nothing without knowing the denominator and the date. "46% remaining" is immediately interpretable. This became the single most consequential interface decision in the product.
Attribution is emotionally loaded. Manual tracking forces someone into the accountant role, and that person becomes the one asking where the money went. When the system captures who logged what automatically, the record stops being an accusation and becomes a fact.
Households aren't uniformly stable. Some want to set a number once and stop thinking about it. Others have variable income and need to move it mid-month. Forcing either group into the other's model breaks the habit within weeks.
Logging has a friction ceiling. An expense entry competes with walking out of a store. Anything past a handful of fields doesn't get logged, and an unlogged expense corrupts the only number the product exists to protect.
STRATEGY & DESIGN RATIONALE
STRATEGY & DESIGN RATIONALE
One number, expressed as a proportion. The dashboard hero is a radial ring reading a live remaining-budget percentage, with a supporting exact-dollar figure beneath it. The percentage carries the instant read; the dollars carry the precision. Every other decision in the product serves keeping that figure trustworthy.
Two budget models, named in the user's language. Automatic is set-and-forget, a recurring amount that reinstates monthly, indefinitely. Manual trades convenience for control, holding for the current month only. The active mode stays labelled on the dashboard card rather than buried in settings, because a household that forgets which model it's on will eventually be surprised by its own balance.
Reset the budget, archive the month. Every month is saved automatically and reachable through month navigation. This resolves the core tension in a recurring budget: users need a clean slate to spend against and a durable record to look back on. Treating those as two different requirements instead of one compromise is what made the reset behaviour safe.
Three lenses, three questions. Spending is summarised by person (who), by method (how), and by category (where), each with its own visual treatment, each answerable at a glance. The same two dimensions then reappear as filter chips over the entry list, so a summary insight can be pulled apart into individual transactions without leaving the page.
Capture in seconds. Amount, category, payment method, optional description. Date defaults to today but stays editable for the receipt found in a coat pocket. Author and timestamp are never asked for. Ten categories enough to be meaningful, few enough to pick without reading.
Mistakes are expected, not punished. Every entry can be edited or deleted inline, because real logging is messy. Attribution and timestamps persist regardless, so tolerance for error never becomes tolerance for an unreliable ledger.
A system underneath the screens, not just a look. The interface runs on a documented set of semantic design tokens rather than one-off styling choices, one type family (DM Sans) at named sizes, a fixed 12px/16px radius scale, a category-color palette explicitly constrained so no category can ever collide with app chrome, and light/dark themes that share the same token names and differ only in value. Every component: buttons, filter chips, cards, modals, avatars is documented against its live source, so the system describes what's actually running, not an aspirational spec that drifts from the code.
One number, expressed as a proportion. The dashboard hero is a radial ring reading a live remaining-budget percentage, with a supporting exact-dollar figure beneath it. The percentage carries the instant read; the dollars carry the precision. Every other decision in the product serves keeping that figure trustworthy.
Two budget models, named in the user's language. Automatic is set-and-forget, a recurring amount that reinstates monthly, indefinitely. Manual trades convenience for control, holding for the current month only. The active mode stays labelled on the dashboard card rather than buried in settings, because a household that forgets which model it's on will eventually be surprised by its own balance.
Reset the budget, archive the month. Every month is saved automatically and reachable through month navigation. This resolves the core tension in a recurring budget: users need a clean slate to spend against and a durable record to look back on. Treating those as two different requirements instead of one compromise is what made the reset behaviour safe.
Three lenses, three questions. Spending is summarised by person (who), by method (how), and by category (where), each with its own visual treatment, each answerable at a glance. The same two dimensions then reappear as filter chips over the entry list, so a summary insight can be pulled apart into individual transactions without leaving the page.
Capture in seconds. Amount, category, payment method, optional description. Date defaults to today but stays editable for the receipt found in a coat pocket. Author and timestamp are never asked for. Ten categories enough to be meaningful, few enough to pick without reading.
Mistakes are expected, not punished. Every entry can be edited or deleted inline, because real logging is messy. Attribution and timestamps persist regardless, so tolerance for error never becomes tolerance for an unreliable ledger.
A system underneath the screens, not just a look. The interface runs on a documented set of semantic design tokens rather than one-off styling choices, one type family (DM Sans) at named sizes, a fixed 12px/16px radius scale, a category-color palette explicitly constrained so no category can ever collide with app chrome, and light/dark themes that share the same token names and differ only in value. Every component: buttons, filter chips, cards, modals, avatars is documented against its live source, so the system describes what's actually running, not an aspirational spec that drifts from the code.
STRATEGY & DESIGN RATIONALE
One number, expressed as a proportion. The dashboard hero is a radial ring reading a live remaining-budget percentage, with a supporting exact-dollar figure beneath it. The percentage carries the instant read; the dollars carry the precision. Every other decision in the product serves keeping that figure trustworthy.
Two budget models, named in the user's language. Automatic is set-and-forget, a recurring amount that reinstates monthly, indefinitely. Manual trades convenience for control, holding for the current month only. The active mode stays labelled on the dashboard card rather than buried in settings, because a household that forgets which model it's on will eventually be surprised by its own balance.
Reset the budget, archive the month. Every month is saved automatically and reachable through month navigation. This resolves the core tension in a recurring budget: users need a clean slate to spend against and a durable record to look back on. Treating those as two different requirements instead of one compromise is what made the reset behaviour safe.
Three lenses, three questions. Spending is summarised by person (who), by method (how), and by category (where), each with its own visual treatment, each answerable at a glance. The same two dimensions then reappear as filter chips over the entry list, so a summary insight can be pulled apart into individual transactions without leaving the page.
Capture in seconds. Amount, category, payment method, optional description. Date defaults to today but stays editable for the receipt found in a coat pocket. Author and timestamp are never asked for. Ten categories enough to be meaningful, few enough to pick without reading.
Mistakes are expected, not punished. Every entry can be edited or deleted inline, because real logging is messy. Attribution and timestamps persist regardless, so tolerance for error never becomes tolerance for an unreliable ledger.
A system underneath the screens, not just a look. The interface runs on a documented set of semantic design tokens rather than one-off styling choices, one type family (DM Sans) at named sizes, a fixed 12px/16px radius scale, a category-color palette explicitly constrained so no category can ever collide with app chrome, and light/dark themes that share the same token names and differ only in value. Every component: buttons, filter chips, cards, modals, avatars is documented against its live source, so the system describes what's actually running, not an aspirational spec that drifts from the code.
PROCESS & ITERATION
PROCESS & ITERATION
I started in Cursor to get a working prototype in front of real spending as fast as possible, then moved the project to Claude Code to centralize the workflow. Multi-user state, authentication, month-boundary logic, and later a full design system needed a tool that could reason across the whole codebase.
I built in vertical slices, putting each into live household use before starting the next:
Capture loop — log an expense, watch the balance move.
Budget models — Automatic and Manual, and the archiving behaviour that makes resets safe.
Summary and filtering — the three lenses, then the filter chips connecting them to individual entries.
Multi-user — invites, roles, attribution, member management.
Design system — auditing the shipped UI, extracting it into tokens and components, and formalizing dark mode.
Using the product between slices surfaced what no design review would have. The percentage-first hero came out of watching the dollar figure fail to answer the question. Month archiving came out of the first reset, and the immediate instinct to look back at what the previous month had actually cost.
The design system itself went through four versioned passes rather than a single pass declared "done": v0.1 named the arbitrary values and consolidated one-off button styles into a single component; v0.3 was a dedicated WCAG 2.1 AA contrast audit against every color pair actually in use, in both themes; v0.4 was layout and interaction, header hierarchy, a month-progress indicator, and instant-apply settings. Each version shipped against the live app rather than a separate spec, and each carries a changelog naming exactly what changed and why.
I started in Cursor to get a working prototype in front of real spending as fast as possible, then moved the project to Claude Code to centralize the workflow. Multi-user state, authentication, month-boundary logic, and later a full design system needed a tool that could reason across the whole codebase.
I built in vertical slices, putting each into live household use before starting the next:
Capture loop — log an expense, watch the balance move.
Budget models — Automatic and Manual, and the archiving behaviour that makes resets safe.
Summary and filtering — the three lenses, then the filter chips connecting them to individual entries.
Multi-user — invites, roles, attribution, member management.
Design system — auditing the shipped UI, extracting it into tokens and components, and formalizing dark mode.
Using the product between slices surfaced what no design review would have. The percentage-first hero came out of watching the dollar figure fail to answer the question. Month archiving came out of the first reset, and the immediate instinct to look back at what the previous month had actually cost.
The design system itself went through four versioned passes rather than a single pass declared "done": v0.1 named the arbitrary values and consolidated one-off button styles into a single component; v0.3 was a dedicated WCAG 2.1 AA contrast audit against every color pair actually in use, in both themes; v0.4 was layout and interaction, header hierarchy, a month-progress indicator, and instant-apply settings. Each version shipped against the live app rather than a separate spec, and each carries a changelog naming exactly what changed and why.
PROCESS & ITERATION
I started in Cursor to get a working prototype in front of real spending as fast as possible, then moved the project to Claude Code to centralize the workflow. Multi-user state, authentication, month-boundary logic, and later a full design system needed a tool that could reason across the whole codebase.
I built in vertical slices, putting each into live household use before starting the next:
Capture loop — log an expense, watch the balance move.
Budget models — Automatic and Manual, and the archiving behaviour that makes resets safe.
Summary and filtering — the three lenses, then the filter chips connecting them to individual entries.
Multi-user — invites, roles, attribution, member management.
Design system — auditing the shipped UI, extracting it into tokens and components, and formalizing dark mode.
Using the product between slices surfaced what no design review would have. The percentage-first hero came out of watching the dollar figure fail to answer the question. Month archiving came out of the first reset, and the immediate instinct to look back at what the previous month had actually cost.
The design system itself went through four versioned passes rather than a single pass declared "done": v0.1 named the arbitrary values and consolidated one-off button styles into a single component; v0.3 was a dedicated WCAG 2.1 AA contrast audit against every color pair actually in use, in both themes; v0.4 was layout and interaction, header hierarchy, a month-progress indicator, and instant-apply settings. Each version shipped against the live app rather than a separate spec, and each carries a changelog naming exactly what changed and why.
COLLABORATION & LEADERSHIP
COLLABORATION & LEADERSHIP
I ran this the way I'd run a small product team: defining the problem, setting the scope line, building, shipping, and supporting real users through a full monthly cycle.
Building the entire stack also changed how I lead. I've spent fifteen years handing specifications to engineers; carrying the implementation myself gave me a far sharper read on which design decisions are cheap, which are expensive, and which look trivial in a mockup and cost days in state management. Month-boundary logic looked like a footnote in the spec and turned out to be the hardest problem in the product. Auditing my own shipped work for accessibility failures and finding seven was its own lesson in how easily contrast debt accumulates without a system to check it against. That calibration now shows up in how I brief and review work with my teams.
I ran this the way I'd run a small product team: defining the problem, setting the scope line, building, shipping, and supporting real users through a full monthly cycle.
Building the entire stack also changed how I lead. I've spent fifteen years handing specifications to engineers; carrying the implementation myself gave me a far sharper read on which design decisions are cheap, which are expensive, and which look trivial in a mockup and cost days in state management. Month-boundary logic looked like a footnote in the spec and turned out to be the hardest problem in the product. Auditing my own shipped work for accessibility failures and finding seven was its own lesson in how easily contrast debt accumulates without a system to check it against. That calibration now shows up in how I brief and review work with my teams.
COLLABORATION & LEADERSHIP
I ran this the way I'd run a small product team: defining the problem, setting the scope line, building, shipping, and supporting real users through a full monthly cycle.
Building the entire stack also changed how I lead. I've spent fifteen years handing specifications to engineers; carrying the implementation myself gave me a far sharper read on which design decisions are cheap, which are expensive, and which look trivial in a mockup and cost days in state management. Month-boundary logic looked like a footnote in the spec and turned out to be the hardest problem in the product. Auditing my own shipped work for accessibility failures and finding seven was its own lesson in how easily contrast debt accumulates without a system to check it against. That calibration now shows up in how I brief and review work with my teams.
CONSTRAINTS & PROBLEM SOLVING
CONSTRAINTS & PROBLEM SOLVING
No development background. AI-assisted tooling made the build possible, but it demanded a specification precision that design documentation rarely requires: intent, edge cases and data relationships had to be described explicitly before anything worked. The constraint improved the product.
No transactional email infrastructure. Rather than block multi-user support on building it, invites generate a shareable link the admin sends through whatever channel they already use. The invite screen states this plainly to the user: automatic inbox email isn't set up yet.
Dark mode surfaced real accessibility debt. Building a second theme against an existing palette isn't a recolor, it's a stress test. It exposed hardcoded hex values that only worked by accident in one theme, gradients that went invisible against a dark background, and color pairs that failed WCAG AA contrast in one theme even though they passed in the other. Fixing this properly meant moving every color to a semantic token and auditing all of them against the standard, rather than patching the individual bugs users would have found first.
No development background. AI-assisted tooling made the build possible, but it demanded a specification precision that design documentation rarely requires: intent, edge cases and data relationships had to be described explicitly before anything worked. The constraint improved the product.
No transactional email infrastructure. Rather than block multi-user support on building it, invites generate a shareable link the admin sends through whatever channel they already use. The invite screen states this plainly to the user: automatic inbox email isn't set up yet.
Dark mode surfaced real accessibility debt. Building a second theme against an existing palette isn't a recolor, it's a stress test. It exposed hardcoded hex values that only worked by accident in one theme, gradients that went invisible against a dark background, and color pairs that failed WCAG AA contrast in one theme even though they passed in the other. Fixing this properly meant moving every color to a semantic token and auditing all of them against the standard, rather than patching the individual bugs users would have found first.
CONSTRAINTS & PROBLEM SOLVING
No development background. AI-assisted tooling made the build possible, but it demanded a specification precision that design documentation rarely requires: intent, edge cases and data relationships had to be described explicitly before anything worked. The constraint improved the product.
No transactional email infrastructure. Rather than block multi-user support on building it, invites generate a shareable link the admin sends through whatever channel they already use. The invite screen states this plainly to the user: automatic inbox email isn't set up yet.
Dark mode surfaced real accessibility debt. Building a second theme against an existing palette isn't a recolor, it's a stress test. It exposed hardcoded hex values that only worked by accident in one theme, gradients that went invisible against a dark background, and color pairs that failed WCAG AA contrast in one theme even though they passed in the other. Fixing this properly meant moving every color to a semantic token and auditing all of them against the standard, rather than patching the individual bugs users would have found first.
FINAL SOLUTION
FINAL SOLUTION
A deployed, multi-user web app in active daily use, backed by a documented, versioned design system.
Percentage-first balance — a radial remaining-budget ring with exact figures beneath
Two budget models — Automatic (recurring, indefinite) or Manual (month-scoped, user-controlled)
Month archiving and navigation — every month saved and browsable
Seconds-long capture — amount, ten categories, payment method, optional note; author and date automatic
Three summary lenses — spend by person, by payment method, and by category
Filterable entry list — chip filters by member and payment method, with inline edit and delete
Household roles — the initiating user becomes admin and manages membership
Link-based invites — generated in-product and shared through any channel
Light and dark themes — token-driven, WCAG 2.1 AA audited, defaulting to light with an opt-in system-matching mode
A living design system — semantic tokens, a documented component library, and a versioned changelog, kept in sync with the shipped source rather than a static spec
A deployed, multi-user web app in active daily use, backed by a documented, versioned design system.
Percentage-first balance — a radial remaining-budget ring with exact figures beneath
Two budget models — Automatic (recurring, indefinite) or Manual (month-scoped, user-controlled)
Month archiving and navigation — every month saved and browsable
Seconds-long capture — amount, ten categories, payment method, optional note; author and date automatic
Three summary lenses — spend by person, by payment method, and by category
Filterable entry list — chip filters by member and payment method, with inline edit and delete
Household roles — the initiating user becomes admin and manages membership
Link-based invites — generated in-product and shared through any channel
Light and dark themes — token-driven, WCAG 2.1 AA audited, defaulting to light with an opt-in system-matching mode
A living design system — semantic tokens, a documented component library, and a versioned changelog, kept in sync with the shipped source rather than a static spec
FINAL SOLUTION
A deployed, multi-user web app in active daily use, backed by a documented, versioned design system.
Percentage-first balance — a radial remaining-budget ring with exact figures beneath
Two budget models — Automatic (recurring, indefinite) or Manual (month-scoped, user-controlled)
Month archiving and navigation — every month saved and browsable
Seconds-long capture — amount, ten categories, payment method, optional note; author and date automatic
Three summary lenses — spend by person, by payment method, and by category
Filterable entry list — chip filters by member and payment method, with inline edit and delete
Household roles — the initiating user becomes admin and manages membership
Link-based invites — generated in-product and shared through any channel
Light and dark themes — token-driven, WCAG 2.1 AA audited, defaulting to light with an opt-in system-matching mode
A living design system — semantic tokens, a documented component library, and a versioned changelog, kept in sync with the shipped source rather than a static spec
OUTCOMES & METRICS
OUTCOMES & METRICS
Dozens of transactions logged in a single month by a two-member household, across cash, debit and credit
A complete monthly cycle survived — including the reset and archive, the moment where budget tools usually lose users
Seven WCAG AA contrast failures identified and resolved across both themes, through a self-directed audit
Four versioned design-system iterations shipped (v0.1–v0.4), each with a documented changelog
Sustained real-world use rather than demo data
Dozens of transactions logged in a single month by a two-member household, across cash, debit and credit
A complete monthly cycle survived — including the reset and archive, the moment where budget tools usually lose users
Seven WCAG AA contrast failures identified and resolved across both themes, through a self-directed audit
Four versioned design-system iterations shipped (v0.1–v0.4), each with a documented changelog
Sustained real-world use rather than demo data
OUTCOMES & METRICS
Dozens of transactions logged in a single month by a two-member household, across cash, debit and credit
A complete monthly cycle survived — including the reset and archive, the moment where budget tools usually lose users
Seven WCAG AA contrast failures identified and resolved across both themes, through a self-directed audit
Four versioned design-system iterations shipped (v0.1–v0.4), each with a documented changelog
Sustained real-world use rather than demo data
KEY LEARNINGS
KEY LEARNINGS
The unit of design was a number, not a screen. Framing the product around keeping one shared figure trustworthy resolved most interface debates before they started.
Format changes meaning more than content does. The same balance shown as dollars and shown as a percentage are not the same product.
Defaults are the product. The single choice at setup: Automatic or Manual, carries more retention weight than anything I designed afterward.
A design system is a discipline, not a deliverable. Writing tokens down didn't just make the UI consistent, it made every accessibility failure visible and fixable in one place instead of scattered across screens. The system paid for itself the first time dark mode exposed seven contrast bugs I wouldn't have caught screen by screen.
AI tooling collapsed the distance between design intent and working software. The tools removed the implementation barrier. They didn't decide what to build, where to stop, or what should happen at midnight on the 1st. That remains design work, and it got more valuable, not less.
The unit of design was a number, not a screen. Framing the product around keeping one shared figure trustworthy resolved most interface debates before they started.
Format changes meaning more than content does. The same balance shown as dollars and shown as a percentage are not the same product.
Defaults are the product. The single choice at setup: Automatic or Manual, carries more retention weight than anything I designed afterward.
A design system is a discipline, not a deliverable. Writing tokens down didn't just make the UI consistent, it made every accessibility failure visible and fixable in one place instead of scattered across screens. The system paid for itself the first time dark mode exposed seven contrast bugs I wouldn't have caught screen by screen.
AI tooling collapsed the distance between design intent and working software. The tools removed the implementation barrier. They didn't decide what to build, where to stop, or what should happen at midnight on the 1st. That remains design work, and it got more valuable, not less.
KEY LEARNINGS
The unit of design was a number, not a screen. Framing the product around keeping one shared figure trustworthy resolved most interface debates before they started.
Format changes meaning more than content does. The same balance shown as dollars and shown as a percentage are not the same product.
Defaults are the product. The single choice at setup: Automatic or Manual, carries more retention weight than anything I designed afterward.
A design system is a discipline, not a deliverable. Writing tokens down didn't just make the UI consistent, it made every accessibility failure visible and fixable in one place instead of scattered across screens. The system paid for itself the first time dark mode exposed seven contrast bugs I wouldn't have caught screen by screen.
AI tooling collapsed the distance between design intent and working software. The tools removed the implementation barrier. They didn't decide what to build, where to stop, or what should happen at midnight on the 1st. That remains design work, and it got more valuable, not less.
©2026 CARLOS RUBIO DESIGN
GO BACK TO TOP
©2026 CARLOS RUBIO DESIGN
GO BACK TO TOP