DEV Community: Adejuwon Oshadipe

Lessons Learned Building Fintech Frontends: Things Nobody Teaches You About Handling Money, State, and User Trust

Adejuwon Oshadipe — Mon, 15 Jun 2026 06:05:13 +0000

When people think about fintech engineering, they often focus on the backend.

Payments.
Bank integrations.
Ledgers.
Settlement systems.

And rightly so—those systems carry enormous responsibility.

But after spending time building frontend experiences around financial products, I've learned that the frontend carries a different kind of responsibility:

User trust.

In many cases, users don't see your backend architecture.

They don't know about your microservices.

They don't care about your event-driven infrastructure.

What they see is the interface.

And when money is involved, every button, loading state, error message, and transaction status affects confidence.

Here are some of the most important lessons I've learned while building fintech frontends.

1. Money Is Different From Every Other Type of Data

In many applications, a small display bug is annoying.

In fintech, it can be terrifying.

Imagine seeing:

₦100,000 become ₦10,000

$1,000.00 become $999.99

even temporarily.

Users immediately assume something is wrong.

That's why money should never be treated like ordinary numbers.

Frontend engineers must understand:

Formatting
Precision
Decimal handling
Currency conversion

A simple rounding mistake can create support tickets and damage trust.

The lesson:

Treat money as a first-class concern, not a display concern.

2. Loading States Matter More Than You Think

One of the fastest ways to create anxiety is silence.

Imagine a user clicks "Send Money."

Nothing happens.

No spinner.

No feedback.

No status update.

Within seconds, they begin asking:

Did it go through?
Should I click again?
Was I charged twice?

Good loading states reduce uncertainty.

Great loading states communicate progress.

When dealing with financial transactions, feedback is not just UX.

It's reassurance.

3. Every Transaction Has More States Than You Expect

Many developers think a transaction is either:

Successful
Failed

Reality is far more complicated.

Transactions often move through states like:

Pending
Processing
Awaiting confirmation
Successful
Reversed
Failed

Frontend systems must be designed to handle every possibility.

The worst bugs often happen when we only design for the happy path.

4. Error Messages Should Build Confidence

Generic errors create frustration.

Messages like:

"Something went wrong"

tell users almost nothing.

Financial applications should aim for clarity.

Users need to know:

What happened
What it means
What they should do next

A good error message reduces support requests.

A great error message preserves trust.

5. Users Care About Outcomes, Not APIs

As engineers, we often think in requests and responses.

Users think in goals.

They don't care that an endpoint returned a 200 status.

They care that:

The transfer arrived
The payment succeeded
The account was funded

Designing around outcomes rather than technical events creates better user experiences.

6. Consistency Builds Trust

One of the most underrated qualities in fintech products is consistency.

The same action should behave the same way every time.

The same status should mean the same thing everywhere.

The same currency should be formatted consistently across the application.

Inconsistency creates doubt.

And doubt is expensive in financial products.

7. Frontend Engineers Are Trust Engineers

This is probably the biggest lesson I've learned.

When building financial products, your job is not simply to render data.

Your job is to help users feel confident about what is happening to their money.

Every interaction contributes to that feeling.

Every loading state.

Every confirmation screen.

Every receipt.

Every transaction history page.

Trust is built through thousands of small decisions.

And frontend engineers play a much larger role in that than most people realise.

Final Thoughts

Building fintech frontends has changed the way I think about software.

I've learned that technical correctness is only part of the equation.

A transaction can be perfectly processed by the backend and still create anxiety if the frontend fails to communicate clearly.

The best financial products don't just move money.

They help users understand what is happening every step of the way.

And that responsibility belongs to all of us who build the experiences people interact with every day.

30 Vue Nuggets from Production Experience 💚

Adejuwon Oshadipe — Wed, 13 May 2026 17:31:17 +0000

Most Vue tutorials teach you how to use Vue.
Very few teach you how Vue behaves in real production systems.

After working on large-scale frontend applications — especially in fintech products where state, performance, and maintainability matter — I’ve realised that the biggest difference between beginner and senior Vue developers is not syntax.

It’s how they think about:

Reactivity
State ownership
Component boundaries
Data flow
Architecture

So I decided to compile 30 practical Vue nuggets pulled from real-world experience building production applications with Vue and Nuxt.

Not theory.
Not tutorial fluff.
Just lessons that consistently matter when applications grow.

🟢 1. ref vs reactive — they solve different problems

One of the earliest Vue mistakes is using reactive for everything.

The mental model is simple:

Use ref for single values
Use reactive for structured objects

ref exists because primitives cannot be proxied like objects. Understanding this distinction early prevents a lot of confusion later in large applications.

🟢 2. v-if and v-show are not interchangeable

They may look similar, but they behave differently.

v-if creates and destroys DOM nodes
v-show only toggles visibility

The real question is:

How often will this element change visibility?

That answer determines which directive you should use.

🟢 3. Props are read-only for a reason

Mutating props breaks predictable data flow.

Vue’s architecture is intentionally directional:

Props go down
Events go up

Once both parent and child can modify the same state, debugging becomes painful.

🟢 4. computed is about caching, not convenience

A method recalculates every render.

A computed property recalculates only when dependencies change.

In small apps, you won’t notice the difference.
In large systems, you absolutely will.

🟢 5. key in v-for is about identity

Vue doesn’t use key to silence warnings.

It uses a key to track identity.

Without proper keys:

DOM reuse becomes incorrect
Component state leaks
Animations break

Using an index as a key is often a hidden bug waiting to happen.

🟢 6. Events scale better than passing functions as props

Passing functions deeply into child components creates coupling.

Events keep communication directional and predictable.

A reusable component should communicate intent — not know parent implementation details.

🟢 7. Most watch usage is unnecessary

A surprising number of watchers should actually be computed properties.

Use:

computed for the derived state
Watch for side effects

That distinction keeps logic cleaner and easier to reason about.

🟢 8. Too many props usually means poor component design

When components need 7–10 props, they’re often doing too much.

A good component accepts meaningful concepts, not scattered fragments of state.

🟢 9. Components re-render more than most developers realise

Every reactive dependency exposed to the template becomes something Vue must track.

The larger the reactive surface area, the more expensive the rendering becomes.

Being intentional with reactivity matters.

🟢 10. Duplicate state creates synchronisation bugs

If the same state exists:

In Pinia
In local refs
In props

…you eventually create inconsistency.

A strong Vue architecture has a clear source of truth.

🟢 11. watch vs watchEffect

The difference is precision.

Watch tracks explicit dependencies
watchEffect tracks everything accessed during execution

Convenience is nice. Precision scales better.

🟢 12. Watchers should be rare

If a watcher is simply updating another reactive value, it’s often a sign that computed properties were misunderstood.

Watchers are not state management tools.

🟢 13. Composables should encapsulate logic, not become hidden stores

A composable that secretly acts like a global state becomes difficult to reason about.

Good composables:

Encapsulate reusable behavior
Expose minimal state
Avoid hidden coupling
🟢 14. Not everything belongs in Pinia

Global state should hold application-wide concerns:

Auth
Shared API data
Permissions

Not:

Modal visibility
Form input values
Dropdown state

Local UI state should stay local.

🟢 15. Dynamic components simplify templates

Large v-if trees quickly become difficult to maintain.

Dynamic components help templates stay declarative instead of becoming logic-heavy.

🟢 16. Slots are a scalability tool

Slots are not just placeholders.

They allow structural flexibility without duplicating components.

This becomes incredibly powerful in design systems and reusable UI libraries.

🟢 17. Async state needs structure

Scattered refs like:

loading
error
data

across multiple components eventually becomes chaos.

Treat async state as a single structured concern.

🟢 18. Prop drilling is often a structural problem

Passing props through many layers usually means state placement needs reconsideration.

Composables and provide/inject exist for a reason.

🟢 19. Folder structure influences architecture

When everything lives in components/, architecture eventually degrades.

Good structure encourages separation of concerns:

Components
Stores
Services
Composables

Organisation affects maintainability more than people realise.

🟢 20. Hard-to-read components are trying to do too much

A good component should be understandable quickly.

If understanding a component requires scrolling endlessly, the boundaries are likely wrong.

🟢 21. Scalable composables feel like tools, not dependencies

Reusable composables should avoid assumptions about pages or layouts.

The more assumptions a composable makes, the less reusable it becomes.

🟢 22. Tight coupling kills flexibility

Coupling often hides inside “convenient” shortcuts.

Components that deeply understand each other become hard to refactor independently.

Loose coupling is one of the most underrated frontend engineering skills.

🟢 23. Co-locate state whenever possible

The best place for a state is usually the closest possible place to where it’s used.

An over-centralised state creates unnecessary complexity.

🟢 24. Large reactive objects can become performance traps

Vue tracks reactivity deeply.

Passing large objects unnecessarily increases tracking overhead and rendering cost.

Smaller reactive boundaries scale better.

🟢 25. Separate UI state from server state

This distinction matters enormously in production apps.

UI state:

Tabs
Filters
Modals

Server state:

API data
Cached responses
Backend truth

Mixing them creates confusion and unpredictable resets.

🟢 26. Too many emits signals poor boundaries

A child component emitting many different events usually indicates responsibility overload.

Smaller, focused components scale better than “super components.”

🟢 27. Complex forms need architecture

Large forms become difficult because developers treat them like collections of inputs instead of systems.

Good form architecture matters more than styling.

🟢 28. Reactivity debugging starts with dependency tracing

Most Vue bugs are not random.

They’re dependency misunderstandings.

Understanding what Vue is tracking internally dramatically improves debugging speed.

🟢 29. Simple components scale better than clever ones

The most maintainable frontend systems are often the least “impressive.”

Predictability scales better than cleverness.

🟢 30. Senior Vue developers think in data flow

Beginners focus on features.

Experienced engineers focus on:

State ownership
Flow direction
Component responsibility
Long-term maintainability

That mindset shift changes everything.

Final Thoughts

Vue is approachable, but building scalable Vue systems still requires engineering discipline.

The framework gives developers incredible flexibility.
The challenge is learning which patterns continue to work as applications grow.

Over time, I’ve realized that good Vue architecture is less about mastering APIs and more about mastering:

Simplicity
Boundaries
Predictability
Data flow

And honestly, those lessons apply far beyond Vue itself.