DEV Community: Rizwan Saleem

TypeScript Unknown States in Open Banking Consent Flows

Rizwan Saleem — Fri, 29 May 2026 20:40:18 +0000

TypeScript Unknown States in Open Banking Consent Flows

Open banking frontend work is full of states that look small in the UI but carry real product trust consequences.

A consent journey can move through loading, redirecting, returning, authorising, partially authorised, expired, failed, cancelled, and retryable states. If the frontend treats those states as a loose set of booleans, the experience can quickly become confusing: a spinner that never explains itself, a success message that appears too early, or an error state that makes a recoverable journey feel broken.

TypeScript is useful here because it encourages the team to name uncertainty.

Instead of modelling a consent flow as:

isLoading: boolean
hasError: boolean
isComplete: boolean

I prefer thinking in explicit states:

type ConsentState =
  | { status: 'idle' }
  | { status: 'starting' }
  | { status: 'redirecting-to-bank' }
  | { status: 'returning-from-bank' }
  | { status: 'authorised' }
  | { status: 'partially-authorised'; missingScopes: string[] }
  | { status: 'expired' }
  | { status: 'cancelled-by-user' }
  | { status: 'retryable-error'; message: string }
  | { status: 'blocked-error'; message: string }

This does not solve every product problem, but it changes the engineering conversation. The team is no longer asking only “does the page work?” It can ask better questions:

What does the user see while they are leaving the app?
What happens when they come back without completing consent?
Which errors are safe to retry?
Which messages need to avoid blame or panic?
Which state should analytics record?
Which state should support or operations teams recognise later?

AI-assisted coding can speed up the component work, but it should not be allowed to flatten product risk into a generic loading/error/success pattern. In regulated or trust-sensitive journeys, human judgement still needs to review the states, labels, transitions, and fallback paths.

For React, Next.js, and TypeScript teams, the goal is not to create complicated types for their own sake. The goal is to make uncertainty visible before it becomes user confusion.

That is the difference between a UI that merely renders data and a frontend system that earns trust.

— Rizwan Saleem

Rizwan Saleem is a UK-based Lead Frontend Developer, AI/LLM practitioner, fintech/open banking engineer, software engineer, and startup founder.

Website: https://rizwansaleem.co

Internal/backlink suggestions

Link from a future Frontend Engineering or Open Banking article hub on rizwansaleem.co.
If published on DEV.to, Hashnode, Medium, or Substack, include one natural canonical backlink to https://rizwansaleem.co in the author footer.
Cross-link later to drafts about accessible loading states, open banking frontend risk, and AI-assisted frontend testing.

Next.js Server and Client Boundaries Are Product Decisions, Not Just Framework Details

Rizwan Saleem — Fri, 29 May 2026 20:30:18 +0000

Next.js Server and Client Boundaries Are Product Decisions, Not Just Framework Details

One of the easiest mistakes in modern frontend development is treating server/client boundaries as a technical afterthought.

In Next.js, the choice between server-side work and client-side interactivity can look like a framework detail. Add a directive, move some state, fetch data in a different place, and the page works.

But that boundary is rarely neutral.

It affects performance, privacy, loading states, bundle size, reliability, maintainability, and the way a user experiences trust.

For engineers working with React, Next.js, TypeScript, AI-assisted workflows, fintech interfaces, or open banking-style products, that distinction matters.

A working UI is not always a well-designed boundary

AI tools are good at producing plausible React and Next.js code quickly. They can scaffold a component, suggest a data fetch, wire up state, and create a passable interface.

That speed is useful.

But generated code often optimises for completion, not responsibility.

A component may work locally while still raising important questions:

Is this data being sent to the browser unnecessarily?
Is the interaction genuinely client-side, or did we make it client-side for convenience?
Are we increasing JavaScript for users who only need static content?
Are loading, failure, empty, and retry states clearly represented?
Are types describing the real contract, or just silencing errors?

A frontend engineer’s job is not only to make the interface render. It is to decide where the logic should live and what trade-offs the product is accepting.

The boundary affects user trust

Users do not care whether a component is a server component, client component, route handler, or API response.

They care whether the product feels fast, clear, safe, and reliable.

That is especially important in domains where trust matters: fintech, open banking, identity, forms, payments, dashboards, and account flows.

A small boundary decision can change the experience:

A server-rendered page may feel faster and more stable.
A client-heavy flow may support rich interaction, but increase loading cost.
A poorly placed data fetch may create confusing loading states.
An unclear error path may make users unsure whether an action succeeded.
An unnecessary client-side payload may expose data or implementation assumptions that did not need to be there.

These are product questions, not only engineering questions.

A practical review checklist

When reviewing a Next.js component or AI-generated implementation, I use a simple boundary checklist:

1. Interaction

Does this component need browser-only behaviour such as local state, event handlers, focus management, drag/drop, or live interaction?

If not, keep it server-side where possible.

2. Data

Does the browser need this data, or only the rendered result?

Avoid moving data client-side just because it is convenient.

3. Performance

What is the JavaScript cost of this decision?

A small component can still pull a larger dependency tree into the client bundle.

4. Failure states

What does the user see when the request fails, times out, returns empty data, or needs retry?

The boundary should not hide failure. It should make recovery clear.

5. Types

Do TypeScript types explain the contract between server, client, API, and UI?

Good types help future engineers understand what is allowed, optional, delayed, or unsafe.

6. AI review

If AI generated the code, ask it to critique the boundary decision, not only the syntax.

Useful prompts include:

Review this Next.js component for unnecessary client-side state, avoidable bundle cost, unclear data boundaries, missing loading/error states, and TypeScript contract weaknesses.

or:

Suggest which parts of this implementation should remain server-side and which parts genuinely need client-side interactivity. Explain the trade-offs.

The engineer still owns the judgement

AI can speed up implementation, comparison, refactoring, and review.

It can suggest alternatives and expose edge cases.

But it cannot take responsibility for the product boundary.

That responsibility sits with the engineer and the team.

For me, frontend engineering is where system decisions become visible to users. React, Next.js, TypeScript, AI tools, and product thinking all meet at that edge.

A good boundary is not just technically valid.

It is clear, intentional, maintainable, and respectful of the user’s time and trust.

That is the work.

Rizwan Saleem — https://rizwansaleem.co

Frontend Release Notes as Product Trust Work | Rizwan Saleem

Rizwan Saleem — Fri, 29 May 2026 20:20:33 +0000

Frontend release notes as product trust work

Release notes are often treated as an afterthought: a short line at the end of a sprint, a ticket number, or a vague message like “improvements and bug fixes.”

For frontend teams, that is a missed opportunity.

A useful release note is not only a marketing update. It is a small public contract between the product and the people using it. It tells users what changed, why it changed, and what kind of engineering judgement sits behind the interface.

That matters in ordinary software. It matters even more in fintech, open banking, and AI-assisted software engineering.

What good frontend release notes should explain

A practical frontend release note should usually answer five questions:

What changed in the interface?
Why does the change matter to users?
Which states were considered — loading, empty, error, retry, disabled, success?
Did accessibility, validation, or copy change?
What is still intentionally limited or being improved?

That level of clarity helps avoid vague claims. It also gives product, design, engineering, support, and compliance-minded teams a shared record of what was actually shipped.

Why this matters for React, Next.js, and TypeScript teams

Frontend work is full of decisions that can look small from the outside:

moving a boundary between server and client components
changing a form validation rule
adding a retry state
tightening a TypeScript type
changing an error message
making a loading state more accessible
making an AI-assisted refactor safer before merge

Each of those decisions can affect user trust.

When teams document them clearly, they build a better engineering memory. When they hide them behind generic release notes, the product loses context.

AI-assisted engineering makes this more important, not less

AI tools can help teams draft code, explore alternatives, and speed up review. But they do not remove the need for human judgement.

If anything, AI-assisted work makes release notes more important because teams need to be clearer about product intent:

what was changed by design
what was preserved deliberately
which edge cases were reviewed
where human judgement overruled a generated suggestion

The goal is not to mention AI for attention. The goal is to keep ownership of the user experience.

A simple release-note template

For frontend changes, I like a simple structure:

Changed: What changed in plain language.

Why: The product or user reason.

User impact: What users may notice.

Engineering note: Relevant React, Next.js, TypeScript, accessibility, performance, or state-management detail.

Known limits: What is not solved yet.

This keeps the note practical without turning it into a long essay.

Credibility compounds through small decisions

My core line is: “I was not born with a way out, so I built one.”

That applies to more than career growth. It also shapes how I think about software. Credibility is rarely built through one dramatic announcement. It compounds through small, honest decisions: clearer states, safer types, better wording, cleaner boundaries, and transparent notes about what shipped.

Frontend release notes are one of those small decisions.

They tell users and teams: we are paying attention.

— Rizwan Saleem

UK-based Lead Frontend Developer, AI/LLM practitioner, fintech/open banking engineer, software engineer, and startup founder.

https://rizwansaleem.co

AI-assisted refactoring without losing product intent | Rizwan Saleem

Rizwan Saleem — Fri, 29 May 2026 20:10:19 +0000

AI-assisted refactoring without losing product intent

Refactoring is not only a code-cleanliness exercise. In frontend engineering, refactoring can change how people experience a product: how quickly a screen becomes useful, how a form explains failure, how a loading state reduces uncertainty, and how accessible the interface remains when something unexpected happens.

That is why AI-assisted refactoring needs more than a prompt that says “make this cleaner”.

Cleaner code is useful, but not if the new version silently removes product intent.

A component usually contains more context than its syntax shows. Some of that context is obvious: props, state, validation, API calls, and rendering branches. Some of it is hidden in the history of the product: a condition added because real users got confused, a loading state added because a financial action felt risky, an error message added because support saw the same issue repeatedly.

AI can help with structure, naming, simplification, test ideas, and alternative implementations. But the engineer still has to protect the things the model cannot fully know.

Before asking AI to refactor frontend code, I like to make the intent explicit:

What user problem does this component or flow solve?
Which states are business-critical?
What can fail?
What should be visible to screen readers?
What should happen while data is loading?
Which behaviours are relied on by users, support, or compliance-heavy product flows?

This is especially important in fintech and open banking interfaces, where frontend decisions are often trust decisions. Consent screens, transaction states, permissions, error recovery, and account-connection flows should not be treated as visual details. They are part of the product contract.

A safer AI-assisted workflow looks like this:

Document the current intent.

Write a short summary of what the code is supposed to protect before asking for changes.
Ask for options, not one rewrite.

A few alternatives make trade-offs easier to compare.
Review the diff against behaviour.

Do not only ask whether the code is shorter. Ask whether loading, error, empty, disabled, and accessibility states survived.
Add or update tests around user outcomes.

TypeScript can catch many mistakes, but product trust also needs behavioural tests.
Keep the final decision human-owned.

AI can accelerate mechanical work, but the engineer owns the context, risk, and release decision.

Used well, AI can make frontend refactoring faster and more deliberate. Used carelessly, it can make teams overconfident while removing the small behaviours that made a product reliable.

The goal is not to avoid AI. The goal is to use it with engineering judgement.

I am Rizwan Saleem, a UK-based Lead Frontend Developer, AI/LLM practitioner, fintech/open banking engineer, software engineer, and startup founder. My core line is: “I was not born with a way out, so I built one.”

More about my work: https://rizwansaleem.co

AI-Assisted Frontend Testing: A Practical Contract for React and TypeScript Teams

Rizwan Saleem — Fri, 29 May 2026 20:00:19 +0000

AI-assisted frontend testing is a contract, not a checkbox

AI can make frontend testing feel easier. It can generate test cases, suggest edge states, explain mocking patterns, and help turn vague requirements into clearer assertions.

That is useful.

But it also creates a risk: teams may confuse more test code with more product confidence.

In frontend engineering, especially in user-facing flows built with React, Next.js, and TypeScript, testing is not only about proving a component renders. It is about protecting trust at the exact moment a user depends on the interface.

The happy path is rarely where trust breaks

AI tools are usually good at producing obvious tests:

renders the component
submits the form
shows a success message
handles a basic error

Those are a start, not the finish.

The more important questions are usually closer to product risk:

What happens if the API returns partial data?
What happens if loading takes longer than expected?
What happens if the user refreshes midway through a flow?
What happens if consent is denied or expires?
What happens if validation tells the developer what failed but not the user?
What happens if the interface works visually but fails for keyboard users?

This is where frontend testing becomes less about coverage percentages and more about judgement.

A practical AI-assisted testing loop

A useful workflow is to treat AI as a second reviewer, not the owner of the test strategy.

Describe the user journey clearly

Write the flow in plain English before asking for tests. Include the user goal, the failure modes, and the trust-sensitive moments.
Ask for missing edge cases

Instead of asking only for test code, ask: “What could break user trust in this flow?”
Group tests by risk

Separate rendering tests, interaction tests, accessibility checks, error states, and data-boundary cases.
Use TypeScript to tighten assumptions

If a test requires impossible mock data, the type model may be hiding a product ambiguity.
Review generated tests like production code

AI-generated tests can assert the wrong thing confidently. The engineer still needs to ask whether the assertion protects the user, not just the implementation.

The frontend testing contract

For me, a stronger frontend testing mindset asks four questions:

Does the interface explain what is happening?
Does it fail safely when the system is uncertain?
Does it remain usable across accessibility needs?
Does it protect the user’s intent when data, consent, or network conditions change?

That mindset matters in fintech and open banking flows, but it also applies to any product where the UI carries trust.

AI can accelerate the work. It can suggest scenarios that humans miss. It can help generate test scaffolding faster.

But the final responsibility remains human.

The goal is not to say, “AI wrote our tests.”

The goal is to say, “Our tests describe the contract we are making with the user.”

— Rizwan Saleem

UK-based Lead Frontend Developer, AI/LLM practitioner, fintech/open banking engineer, software engineer, and startup founder.

Website: https://rizwansaleem.co

Accessible Loading States in React Fintech Apps: A Practical Trust Checklist

Rizwan Saleem — Fri, 29 May 2026 19:50:18 +0000

Accessible loading states are product trust work in React fintech apps

A loading state looks small until the user is waiting for something important.

In ordinary software, a vague spinner is annoying. In fintech and open banking interfaces, it can create confusion at exactly the wrong moment: connecting an account, approving consent, fetching balances, confirming a payment, or recovering from a failed request.

That is why I do not see loading states as visual polish. I see them as part of the trust contract between the product and the user.

The problem with vague loading

A generic spinner often says only one thing: “wait”.

But users usually need more than that. They need to understand:

what action is in progress,
whether they can safely leave or retry,
whether pressing again may duplicate an action,
whether the system is waiting on a third party,
whether the state is still active or has silently failed.

In a fintech flow, those details are not minor. They affect confidence.

A practical checklist

When I review a React or Next.js flow, I like to ask:

Does the loading state describe the actual operation?
Is the previous user context preserved instead of blanked out?
Are buttons disabled only when that is genuinely safer?
Is there a timeout or recovery path?
Is the state understandable without colour alone?
Does it work with keyboard navigation and screen readers?
Are success, failure, empty, partial, and retry states distinct?
Does the TypeScript model make impossible states harder to represent?

A useful loading state is not just an animation. It is a small explanation of system uncertainty.

Where TypeScript helps

TypeScript cannot design the experience for you, but it can make state clearer.

Instead of treating a request as a loose collection of booleans, frontend teams can model the flow more explicitly:

idle,
loading,
success,
empty,
partial,
failed,
retrying,
expired.

That structure makes it easier to avoid impossible combinations like showing a success message and a retry error at the same time.

Where AI helps — and where it does not

AI-assisted engineering can be useful here. It can help generate test cases, review copy variations, identify missing edge states, and compare implementation options.

But AI should not be allowed to decide the product risk on its own.

The engineer still needs to ask: if this state is wrong, confusing, or inaccessible, what might the user do next? In financial interfaces, that question matters.

The takeaway

Frontend engineering is not only about rendering a screen quickly. It is about helping people understand what the system is doing, especially when the system is uncertain.

Good loading states reduce doubt. Good error states reduce panic. Good state modelling reduces accidental product risk.

That is why accessible loading states deserve more attention in React, Next.js, TypeScript, fintech, and open banking work.

They are small pieces of UI, but they carry a lot of trust.

— Rizwan Saleem

UK-based Lead Frontend Developer, AI/LLM practitioner, fintech/open banking engineer, software engineer, and startup founder

https://rizwansaleem.co

Next.js Metadata Is an Entity Trust Layer, Not Just SEO Decoration

Rizwan Saleem — Fri, 29 May 2026 19:47:19 +0000

Next.js Metadata Is Not Decoration; It Is an Entity Trust Layer

A lot of frontend teams treat metadata as something that gets added at the end of a project.

The page works. The design is approved. The components are shipped. Then someone remembers the title tag, meta description, Open Graph image, and maybe a canonical URL.

That approach misses something important: metadata is not decoration. It is part of how a website explains itself.

For personal websites, startup sites, technical blogs, and portfolio pages, this explanation becomes part of public trust.

The web has to understand what a page represents

A human can land on a page and quickly infer context from the design, writing, navigation, and tone.

Search engines and social platforms need more explicit signals.

They need to understand:

What is this page about?
Who or what is the primary entity?
Is this the canonical version?
Which profiles or sources support the same identity?
What should appear when the page is shared?
Does the metadata match the visible content?

This is where frontend engineering and technical SEO overlap.

In a Next.js project, metadata should be treated as part of the page contract, not as an afterthought.

What I check on a serious personal or founder website

For a personal brand site, I want the basic entity signals to be boringly consistent.

That usually means:

A clear homepage title using the person’s real name and primary positioning.
A meta description that matches the visible homepage copy.
A canonical URL for every indexable page.
Open Graph and Twitter/X card data that creates accurate link previews.
Person schema only where the facts are verified.
sameAs links pointing to official public profiles.
Internal links between biography, articles, projects, and contact pages.
No exaggerated claims in metadata that are not supported in the page body.

For Rizwan Saleem, the approved public positioning is straightforward: UK-based Lead Frontend Developer, AI/LLM practitioner, fintech/open banking engineer, software engineer, and startup founder.

That wording should remain consistent across the website, schema, and public profiles wherever possible.

Consistency beats hype

A common mistake in personal-brand SEO is trying to make every field sound bigger than the truth.

That is risky.

Search systems and readers are both good at detecting inconsistency. If a title tag claims “world-leading expert” but the actual site shows a normal professional portfolio, the metadata is not helping. It is creating doubt.

Good metadata does the opposite. It reduces ambiguity.

It says: this is the person, this is the topic, this is the canonical website, these are the supporting profiles, and this is what the page honestly contains.

The frontend takeaway

If you work with React, Next.js, or TypeScript, metadata deserves the same engineering discipline as UI states, accessibility, and data contracts.

A useful checklist:

Does every important page have a unique title?
Does the description reflect the visible content?
Are canonical URLs correct?
Do social previews look professional and accurate?
Is schema factual and current?
Are profile links consistent with the official identity?
Are internal links helping users and crawlers understand the site?

None of this is glamorous. But it compounds.

A clear site is easier to trust. A consistent entity is easier to understand. A technically clean personal website gives every future article, profile, and backlink a stronger home base.

The goal is not to trick the algorithm.

The goal is to make the truth easier to parse.

Rizwan Saleem — https://rizwansaleem.co

Manchester Tech Career Growth: Credibility Compounds in Small Technical Decisions

Rizwan Saleem — Fri, 29 May 2026 18:30:28 +0000

Manchester Tech Career Growth: Credibility Compounds in Small Technical Decisions

A serious software career is rarely built from one dramatic breakthrough.

Most of it is built through small technical decisions that compound over time.

That is one of the most useful lessons I have learned as a UK-based frontend developer working across React, Next.js, TypeScript, AI-assisted engineering, and fintech/open banking products.

The visible parts of a product carry a lot of trust. Users may never see the architecture diagram, the deployment pipeline, or the internal debate behind a feature. They do see the loading state. They do feel the error flow. They do notice when a form loses their data, when a consent screen is unclear, or when an interface behaves differently from what the product promised.

That is why frontend engineering is not only about making screens look correct. It is about translating product risk, data boundaries, accessibility, and user intent into an experience people can rely on.

The small decisions that matter

Credibility often compounds through decisions that look minor in isolation:

Making a TypeScript type more honest instead of forcing a value through the system.
Writing loading states that explain what is happening instead of leaving users uncertain.
Designing error messages that help recovery rather than shifting blame.
Keeping pull requests small enough for proper review.
Questioning an AI-generated implementation before merging it.
Choosing boring, stable code when the product needs reliability more than novelty.
Asking whether a frontend shortcut creates risk for accessibility, consent, or user trust.

None of these decisions create instant visibility. But repeated over months and years, they shape the kind of engineer people trust with important interfaces.

AI changes speed, not responsibility

AI-assisted software engineering makes this even more important.

AI tools can help with scaffolding, refactoring, comparison, and exploration. They can make a developer faster. But speed is not the same as judgement.

The developer still owns the decision to ship. The developer still needs to understand the product context, the user impact, the data boundary, the accessibility trade-off, and the failure mode.

For frontend engineers, this matters because AI can generate UI code that looks plausible while missing the messy parts that make an interface trustworthy: edge states, empty states, validation, progressive disclosure, keyboard use, responsive behaviour, and recovery paths.

A UK tech career is built through trust

Building a tech career in the UK has taught me that consistency matters more than performance theatre.

You do not need to pretend to be the loudest expert in the room. You need to keep improving your judgement, communicate clearly, and deliver work that makes the product stronger.

That is the practical version of reinvention for me.

I was not born with a way out, so I built one. But building a way out was not one heroic moment. It was a long sequence of learning, shipping, correcting, and getting better at the next decision.

Takeaway

If you are trying to grow as a developer, do not underestimate the small decisions.

A clearer type, a better error state, a more careful review, and a more honest conversation about product risk all count.

Careers compound the same way systems do: through repeated decisions that either create trust or erode it.

Make the next decision more trustworthy than the last one.

— Rizwan Saleem

Lead Frontend Developer, AI/LLM practitioner, fintech/open banking engineer, software engineer, and startup founder

https://rizwansaleem.co

TypeScript and frontend forms: small details that build user trust | Rizwan Saleem

Rizwan Saleem — Fri, 29 May 2026 18:20:27 +0000

TypeScript and frontend forms: small details that build user trust

A form is one of the easiest parts of a product to underestimate. It can look simple in a design file: labels, inputs, validation, a submit button, and a confirmation state.

In real product work, especially in fintech, open banking, onboarding, or account-related flows, a form often sits at the point where user trust is either strengthened or weakened.

The frontend is not only collecting input. It is explaining the system.

Trust lives in the states around the form

The happy path is only one part of the experience. A reliable form needs to handle the situations where real users actually feel uncertainty:

What happens if the API is slow?
What if the user makes a mistake?
What if the backend rejects a value the frontend allowed?
What if a connection fails halfway through?
What does the user see after submitting?
Can they recover without losing confidence?

These questions are not decoration. They are part of product quality.

In sensitive flows, unclear validation or vague error copy can make the product feel less trustworthy even when the underlying system is working correctly.

TypeScript helps, but it does not replace judgement

TypeScript is valuable because it helps teams make data contracts explicit. A well-typed form flow can reduce avoidable mistakes around optional fields, response shapes, submit states, and error handling.

But types only protect what the team has chosen to model.

Frontend engineers still need to think about the user-facing experience:

Does the validation match the real backend rules?
Are error states specific enough to be useful?
Does the user know whether they can retry?
Are loading states honest without being alarming?
Are accessibility behaviours tested, not assumed?
Does the interface avoid exposing unnecessary sensitive details?

That is where engineering judgement matters.

AI can support the review loop

AI/LLM tools can help by generating edge cases, suggesting tests, reviewing TypeScript contracts, and checking whether a component only handles the happy path.

A useful prompt is not just, “Build this form.”

A better prompt is:

Review this form flow for missing states, accessibility concerns, unclear validation, TypeScript weaknesses, and user recovery paths.

That kind of prompt uses AI to improve thinking, not replace responsibility.

The engineer still has to decide what belongs in the product, what is safe, what is clear, and what is maintainable.

A practical frontend checklist

Before shipping an important form, I like to check:

Are the TypeScript types aligned with the actual API contract?
Are loading, success, empty, and error states all designed?
Are validation messages useful and action-oriented?
Can the user recover from common failures?
Is keyboard navigation and screen-reader behaviour acceptable?
Is sensitive information handled carefully in copy and UI states?
Are AI-generated suggestions reviewed against the product context?

Takeaway

Strong frontend work is not only about components, styling, or framework choices. It is about how the interface helps people understand what is happening.

In products where trust matters, the small details around forms carry a lot of weight.

Good TypeScript helps. Good React and Next.js patterns help. AI-assisted review can help.

But the final standard is still human judgement: make the flow clear, resilient, accessible, and honest.

Rizwan Saleem — https://rizwansaleem.co

Small Frontend Diffs Are Easier to Trust

Rizwan Saleem — Fri, 29 May 2026 18:10:27 +0000

Small diffs make engineering judgement easier

Frontend work is not just about making an interface appear on screen. It is where product intent, domain rules, accessibility, performance, and user trust meet.

That is why the size and shape of a change matters.

A large pull request may contain useful work, but if it combines UI behaviour, API assumptions, TypeScript model changes, styling, copy, and unrelated refactoring, it becomes harder to review properly. Reviewers start scanning instead of reasoning.

Small diffs create a better environment for judgement.

What a reviewable frontend diff usually does

A strong frontend change should make its reasoning visible. It should be clear:

What user problem is being solved — not just which component changed.
Which state transitions are affected — loading, empty, error, retry, success, partial success, or timeout.
Which TypeScript types changed — and whether they describe the real domain rather than only satisfying the compiler.
Which accessibility behaviours are protected — focus, keyboard interaction, labels, and feedback.
Which assumptions are new — especially around API data, permissions, identity, money, or sensitive information.
How safely the change can be rolled back if the assumption proves wrong.

This is useful in every product, but it becomes especially important in fintech and open banking flows, where small interface decisions can affect confidence quickly.

AI increases the need for disciplined review

AI-assisted engineering can speed up implementation. It can suggest patterns, generate tests, explain unfamiliar code, and produce alternatives quickly.

But generated speed can also create bigger, blurrier diffs.

A good engineer still needs to break the work into understandable pieces, challenge the assumptions, and keep ownership of the final decision. AI can help pressure-test a change, but it cannot know the full product context or own the user impact.

A practical checklist before opening a frontend PR

Before opening a pull request, I like to ask:

Can this change be explained in one sentence?
Is unrelated refactoring removed or separated?
Are state changes visible and testable?
Are accessibility and keyboard behaviour still intact?
Are TypeScript types closer to the real domain?
Is there one clear rollback path?
Would another engineer understand the trade-off in a month?

If the answer is no, the diff may need to be smaller.

Clarity compounds

Small diffs are not about slowing teams down. They are about making progress easier to trust.

The best frontend engineering cultures make decisions visible. They reduce hidden risk. They protect user confidence. They leave the codebase easier to work with than they found it.

That is the kind of discipline that compounds over time.

Rizwan Saleem — https://rizwansaleem.co

Frontend leadership means making uncertainty visible | Rizwan Saleem

Rizwan Saleem — Fri, 29 May 2026 18:00:27 +0000

Frontend leadership means making uncertainty visible

Frontend leadership is often described through delivery, architecture, reviews, mentoring, and component systems. Those things matter. But one of the most valuable leadership habits is quieter: making uncertainty visible early enough that the team can respond to it.

Uncertainty is present in almost every product build. Requirements shift. APIs return unexpected shapes. Designs show the happy path more clearly than the failure path. Accessibility issues appear late. Performance costs hide inside small decisions. User trust depends on details that can be easy to miss.

A strong frontend team does not eliminate uncertainty. It exposes it.

The happy path is not the full product

A screen can look complete while still hiding important questions:

What happens when the request is slow?
What should the empty state say?
Can the user recover from this error?
Does keyboard navigation work properly?
Are form errors useful and calm?
Is the TypeScript contract strict enough to protect the flow?
What happens when content is longer than expected?
Does the interface still make sense on a smaller screen?

These are not minor polish tasks. They are part of the product experience.

In frontend engineering, the user often experiences system quality through the interface. Loading states, validation, error messages, accessibility, and data handling become the visible edge of the wider architecture.

Leadership is creating decision clarity

Making uncertainty visible is not about slowing the team down. It is about reducing expensive surprises.

A practical leadership approach is to ask better questions early:

What assumptions are we making?
Which states are missing from the design or ticket?
What can fail, and how should the product respond?
What should be typed, tested, or documented before the work spreads?
Where do we need a product decision rather than an engineering guess?

That last point matters. Some uncertainty is technical. Some is product-level. A frontend leader should know the difference.

AI can help, but judgement still belongs to the engineer

AI/LLM tools are useful for surfacing edge cases, reviewing TypeScript types, suggesting test scenarios, comparing implementation options, and challenging assumptions. Used well, they can make the thinking loop faster.

But AI does not own the product outcome.

The engineering responsibility remains human: decide what is appropriate for the product, the user, the system, and the team. Generated suggestions still need review against accessibility, performance, privacy, reliability, and maintainability.

A simple practice for frontend teams

Before a frontend feature is considered ready, ask the team to capture three things:

the known happy path
the known failure paths
the unresolved assumptions

This small habit can improve reviews, reduce rework, and make collaboration with product, design, backend, and QA more honest.

It also creates better engineering culture. People are less likely to hide uncertainty when leaders treat it as useful information rather than weakness.

Takeaway

Frontend leadership is not only about writing clean components or choosing the right framework. It is about helping teams make better product decisions at the point where technical detail meets user experience.

Make uncertainty visible early.

Name the assumptions. Check the edge cases. Strengthen the contracts. Keep the judgement human.

That is how frontend work becomes more reliable, more trustworthy, and easier to lead.

Rizwan Saleem — https://rizwansaleem.co

A practical AI-assisted engineering checklist for frontend developers | Rizwan Saleem

Rizwan Saleem — Fri, 29 May 2026 17:50:28 +0000

A practical AI-assisted engineering checklist for frontend developers

AI tools are now part of the everyday software workflow for many developers. They can help with scaffolding, debugging, explanation, refactoring, test ideas, documentation, and fast exploration. Used well, they compress the time between question and insight.

But speed is not the same thing as quality.

For frontend developers, this distinction matters because our work sits directly between product logic and human experience. A component is rarely just a component. It may carry accessibility decisions, loading states, validation rules, performance trade-offs, analytics events, error handling, security assumptions, and user trust.

That is why I think AI-assisted engineering needs a disciplined checklist.

1. Understand the problem before asking for code

If the prompt starts before the thinking starts, the output will usually be shallow. Before asking an AI tool to generate a solution, define the user problem, the technical constraint, and the quality bar.

A better prompt often starts with context rather than command: what the component is for, who uses it, what can go wrong, and what stack constraints exist.

2. Ask for trade-offs, not only answers

A code answer can look correct while hiding weak assumptions. Asking for trade-offs forces the tool to surface alternatives: client vs server rendering, controlled vs uncontrolled state, optimistic updates vs explicit confirmation, library vs custom implementation.

The value is not only the final snippet. The value is the comparison.

3. Review generated code like it came from a junior teammate

Generated code deserves a real review. Naming, types, state boundaries, dependencies, accessibility attributes, loading states, testability, and failure paths all need human inspection.

This is not cynicism. It is engineering ownership.

4. Check product-facing details yourself

AI is often good at the happy path and weaker at the lived product path. Frontend quality depends on details such as empty states, long text, keyboard navigation, responsive behaviour, slow networks, API errors, and partially completed forms.

Those details are where users feel the quality of the product.

5. Refactor until the solution fits the system

A generated solution may solve the isolated prompt but still not fit the codebase. The real work is shaping it into the existing architecture, design system, naming conventions, test patterns, and performance expectations.

Good developers do not just paste. They integrate.

6. Keep learning the underlying technology

The strongest AI-assisted developers are not the ones who know the least. They are usually the ones who can judge the output because they understand the fundamentals.

React, Next.js, TypeScript, accessibility, browser behaviour, APIs, and product thinking still matter. AI increases leverage, but leverage without judgement increases risk.

Conclusion

AI can make software engineers faster, but speed only becomes valuable when it is paired with responsibility. My own rule is simple: use AI to accelerate the work, but keep responsibility for the outcome.

You do not need a perfect beginning to build serious technical skill. You need curiosity, discipline, ethics, and the courage to keep learning when no one is clapping yet.

Rizwan Saleem — https://rizwansaleem.co