Brownsmith Dynamics

Services, products, company information, learning, and contact paths in one place.

Digital Systems Built Around User Needs.

These examples show work on public-service guidance and business websites. Each starts with the visitor’s goal, then organizes information and actions around it. For businesses, that means making the offer easier to understand and the next enquiry easier to begin.

Build What Moves India submission

Parivahan: Find a Service by What Happened.

A citizen rarely arrives thinking, “I need the duplicate driving licence service.” They arrive because a licence was lost, damaged, or stolen. Showing every administrative option at once can make the first decision harder and delay the application. The prototype starts with the event and resolves it into the correct service.

This is a functional, independent prototype built with synthetic identity, document, payment, appointment, and notification providers. It is not an official government service or a claim of production integration.

Intent-first Parivahan prototype asking a citizen what they need help with before showing services

Reduce the first decision

Ask what happened before showing the catalogue. “I lost my licence” is a decision a citizen can make with confidence.

Resolve intent visibly

Match the event to a state-specific service, explain the match, and keep correction easier than restarting the search.

Connect the path safely

Use bounded service contracts and MCP tools so a simpler interface can reach complex systems without giving an agent unlimited authority.

Decision Paralysis Is a Service-Design Problem.

Losing a licence creates uncertainty before the website opens: Which service applies? Which documents are needed? Will an office visit be required? A long list of similar services adds another problem. The citizen has to compare terms they do not use and judge rules they have not yet been shown. Postponing the application can feel safer than making the wrong choice.

More options are not automatically harmful. Choice-overload research is mixed, and the effect depends on context. The risk rises when choices are difficult to compare, the person is uncertain about what they need, and the consequences feel important. Those are plausible conditions in a transport service, so the redesign reduces the first choice instead of merely shortening the catalogue.

The interface asks what happened, proposes a matched service, explains why it applies, and lets the citizen correct the interpretation. A muted palette lowers visual noise, but the stronger response is procedural: reveal one useful decision at a time, say what lies ahead, and keep the current state visible.

These are design hypotheses embodied in the prototype, not measured claims about citizen outcomes. The next responsible step would be usability research with real people, including users under time pressure and people who rely on assistive technology.

  • English and Hindi journeys
  • Delhi and Uttarakhand rule configurations
  • Keyboard skip navigation and text-size controls
  • A 320 px / 200% text reflow check
  • Document correction with version history
  • Payment retry and application status tracking
  • Eleven MCP tools for one bounded Uttarakhand journey

The architecture separates service rules from interface code and defines replacement points for production identity, storage, payments, appointments, and notifications. The MCP server calls those boundaries through a bearer-protected route and never hands the assistant direct database or provider access.

The Interface Can Ask Less When the Integration Layer Does More.

Intent-first navigation solves the entrance problem. The citizen describes the event in ordinary language, and the system narrows the service catalogue. MCP connects that match to approved information and actions behind the interface.

The implemented MCP surface has eleven tools for one supported Uttarakhand duplicate-licence journey. It can prepare a draft, record direct-upload metadata, request document pre-approval, confirm a synthetic payment, suggest appointment times, book one chosen slot, and report the current journey state.

The boundaries matter. Real Aadhaar data and document contents must not enter model context. Saving, payment, and booking have separate confirmation gates, while status is read-only. MCP does not cure decision paralysis by itself. It lets an authorised assistant continue one coherent journey without receiving unlimited authority.

Small Websites Still Need a Complete Operating Path.

A basic website is only basic in scope. It still needs a clear offer, responsive design, versioned code, a dependable route for enquiries, and a hosting setup someone can maintain after launch.

Elza International website presenting the manufacturer behind leading Indian brands

Manufacturing website

Elza International

A focused company website for an OEM manufacturer, with a clear visual identity, catalogue discovery, validated enquiries, and a GitHub-backed delivery path.

GitHub-backed version control and deployment workflowValidated lead collection routed into Google Forms
Visit elza.co.in
apnatva.dev portfolio showing its creative display mode and three-way mode switcher

Developer portfolio

apnatva.dev

A personal portfolio with three presentation modes, one underlying body of work, a direct hire route, and a validated lead-collection endpoint.

GitHub-backed version control and deployment workflowValidated lead collection routed into Google Forms
Visit apnatva.dev

Start with Hosting That Fits the First Release.

Hosting should match the application’s runtime, traffic, deployment method, backups, and maintenance needs. If Hostinger fits that assessment, our referral link provides 20% off hosting.

Affiliate disclosure: Brownsmith Dynamics may receive a benefit if you purchase through this link.

What Should Be Easier for Your Customers to Do?

We scope the goal, map the path, and manage the digital work needed to help people find, understand, and enquire about your business.