Back to index
05Work

Dodreams

From dream to plan

My role
Full stack developer
Client
Catsuc Labs
Sector
Consumer product · web
Status
In production

Proprietary code. Private client system — the repository isn’t public.

Numbers

1

dream, many steps

Progress comes from completed steps, not a hand-typed number.

CRUD+

more than a form

The hard part is modeling something subjective without boxing the user in.

A

Context

A dream lives in your head, in a phone note, or in a screenshot of a flight price. Scattered like that it doesn’t move forward — not for lack of will, but because there’s nowhere it exists as a trackable thing.

B

The problem

Modeling something subjective. “Go to Japan” and “learn guitar” don’t share a shape, but they have to fit one structure without becoming a generic form that serves neither. And progress has to be honest: a bar that fills itself doesn’t motivate, it lies.

C

The approach

A dream is the central entity and carries the minimum: what, when, how much and why. Everything else comes from its steps — and progress is derived from them, never typed in. That way one structure serves both a trip with flights and lodging and a goal with no price at all, and the number the person sees actually means something.

D

Modules

01The core entity

Sonhos

What the dream is, with optional deadline and cost — because not every dream has a price, and forcing the field away half the use cases.

02The plan

Etapas

The breakdown into concrete steps. It’s what turns intent into something you can tick off.

03Derived

Progresso

Computed from completed steps. Never a field the user edits — editable progress is decoration.

E

The hard parts

Structure for something shapeless

The temptation was a dream type per case — trip, purchase, goal — each with its own fields. That multiplies the interface and ages fast. A small core with optional fields and free-form steps covers far more cases and stays simple to use.

Progress that doesn’t lie

Letting people drag their own progress bar is easy and useless. Deriving it from steps gives a smaller number at the start — and that is exactly what makes completing a step mean something.

F

What’s mine

  • Domain modeling for dreams and steps, with derived progress
  • The UI for creating, planning and tracking
  • API and PostgreSQL persistence
G

Outcome

A dream stopped being a loose note and became a thing with steps and a deadline. It’s the lightest project on this list and the one that pushed me hardest on modeling — because when the domain is subjective, the schema *is* the product decision.

What I took from it

  1. 01A small core with optional fields covers more cases than a type per situation.
  2. 02A derived number beats a typed one. If the user can edit it, it isn’t a metric.
  3. 03A subjective domain is where modeling stops being a technical detail and becomes the product.

Stack