How I Think

The workflow is the product shape before code exists.

I start by understanding how people describe their work, where the pressure sits, which decisions matter, and what the software must make easier. The technical architecture follows the operating model.

From conversation to architecture

flowchart TD
  A[Listening] --> B[Business stories]
  B --> C[Actors]
  C --> D[Data objects]
  D --> E[Workflows]
  E --> F[Permissions]
  F --> G[Performance constraints]
  G --> H[Architecture]
  H --> I[Technology]

Listening before designing

I deliberately let founders and operators finish explaining their vision before I interrupt. The sequence of their explanation is data: it reveals urgency, language, hidden actors and the parts of the business they already know are fragile.

I am listening for business stories, not features. Who starts the process? Who waits? Who approves? Which object changes state? Which exception makes the team nervous?

Good product engineering starts with restraint. I want the first conversation to reveal the business as it is currently understood, including the parts that are inconsistent, informal or still carried by individual memory. Those details usually explain why a simple feature request is actually a workflow, permission or data-quality problem.

Actors, data and workflows

EthCC is not only a conference website. It is organizers, speakers, schedules, sponsors, content updates and event operations. WeImpactAI is not only AI output. It is human validation, review states and accountability.

I model the nouns and verbs before the screens: actors, business objects, states, transitions, external systems and failure paths. Once those are visible, the interface becomes less arbitrary. The UI is no longer a collection of pages; it is a way for people to move work from one valid state to another.

This is also where product vocabulary matters. If the software uses different language than the team, every interaction creates translation cost. Durable systems tend to preserve the language operators already use, then make that language more structured and inspectable.

Firebase is a tradeoff, not a shortcut

Firebase can be excellent when the product benefits from managed authentication, realtime data, serverless workflows and fast operational leverage. It can also become expensive or awkward when domain boundaries, reporting needs, access rules or integration requirements outgrow the initial shape.

I treat Firebase as an architectural decision with explicit consequences. Firestore data modelling, security rules, Cloud Functions, background jobs, indexes and migration paths need the same care as any backend. The value is speed with discipline, not avoiding architecture.

Performance is product trust

Performance is not only a Lighthouse score. It is whether the application feels like it understands the urgency of the user. Slow admin tools create doubt. Slow public pages lose attention. Slow validation flows make people repeat work or invent side channels.

I prefer static-first delivery when content and interaction patterns allow it, then add dynamic behavior where it creates real leverage. The goal is not to make everything static or everything server-rendered; the goal is to put latency, caching, data freshness and deployment complexity in the right places.

UX polish is operational empathy

Polish is not decoration. It is clear empty states, predictable controls, readable density, helpful validation, consistent language and the absence of tiny frictions that make repeated work feel heavier than it should.

In operational products, the best interface often disappears into the work. It helps people scan, compare, decide and recover from mistakes without making them think about the software itself.

Permissions and multi-tenancy

Permissions are product architecture. They describe ownership, accountability and trust boundaries. If the model is unclear, the UI will keep inventing exceptions: hidden buttons, duplicated pages, manual reviews and fragile admin behavior.

I like multi-tenancy only when the operating model has earned it. Start with the real team and the real workflow. When repeated events, organizations, teams or customer groups appear, promote those patterns into the domain model deliberately instead of guessing them too early.

Pragmatic architecture

I do not choose technologies first. Firebase, Cloud Functions, Astro, Next.js, SvelteKit, serverless functions and traditional backends are tools. The workflow, constraints and future maintenance burden decide.

The architecture should be boring where the business needs reliability and flexible where the product is still learning. That balance is the craft: not overbuilding the first version, not trapping the second one.