Engineering Notebook ยท Product Development
A purpose-built system for communicating complex engineering work to recruiters, technical leaders and senior engineers, using different levels of depth for each reader.
This is not a template website. Its information architecture, user experience, interface design, visual language, editorial system, software architecture and implementation were developed specifically for this portfolio. The project treats communication as a systems problem: identify the stakeholders, define what each reader must understand, select the simplest maintainable architecture and preserve evidence behind every major claim.
Type
Product Development
Status
Active development
Organisation
Independent engineering portfolio
Period
Active development
Technologies
System development flow
The portfolio architecture followed the same sequence used in an engineering programme: identify the stakeholders, define the problem, derive requirements, select the architecture, validate the system and continue operating it.
Methods
At a glance
My role
Product architect, UX/UI designer, editorial architect, developer and technical author.
Project objective
Create a credible, maintainable and public-safe system for communicating multidisciplinary engineering work.
Core stack
Next.js, React, TypeScript and Tailwind CSS.
Content architecture
Engineering Stories, Engineering Notebook and structured portfolio data.
Design approach
Original UX, UI and visual system.
Editorial approach
Evidence-controlled engineering narratives with contribution and IP boundaries.
Delivery approach
Branch-controlled, tested and incrementally released.
Infrastructure cost
Approximately US$8 per year under current usage and hosting limits.
Source links
Technology stack
Next.js
Routing, rendering, metadata and reusable page architecture for current and future editorial systems.
React
Repeated interface patterns for media, metadata, navigation, related content and interactive controls.
TypeScript
Typed content records for statuses, technologies, images, links, sections and metadata.
Tailwind CSS
Responsive states, spacing and design-token usage kept close to the reusable components.
Static and server-rendered editorial content
Fast delivery without a runtime database or application backend for the current publishing model.
Structured repository content
Version-controlled review of evidence, claims, source links, media and publication state.
Git workflow
Branch-controlled development with lint, build and diff review before accepted commits.
ChatGPT and Codex
Retrospective research, evidence reconciliation, editing, implementation assistance and review under human ownership.
The portfolio was designed around reader needs rather than around a website template. Recruiters need role fit, seniority and career scope quickly. Engineering managers need judgement, ownership and delivery evidence. Senior engineers need architecture, trade-offs, testing and lessons. Hiring leaders need commercial impact, leadership breadth and credibility. I also need an accurate, maintainable and public-safe technical record.
A single resume-style page could not serve all of those readers well. The design therefore uses progressive disclosure: a 30-second skim for role fit, a 3-minute technical overview for architecture and decisions, and deeper narratives for readers who want evidence.
Recruiters
Role fit, seniority and career scope within seconds.
Engineering managers
Judgement, ownership, delivery evidence and communication style.
Senior engineers
Architecture, trade-offs, validation and lessons learned.
Hiring leaders
Leadership breadth, commercial relevance and credibility.
The real problem was communicating multidisciplinary engineering work without reducing it to resume bullets, overwhelming non-specialist readers or publishing confidential implementation details.
Traditional resumes are effective for linear career histories, but this career spans product architecture, electronics, RF, mechatronics, software, field validation, programme delivery and technical leadership. Compressing that breadth into short claims removes the evidence and reasoning that make the work credible.
Templates were rejected because the content model and reader journeys were custom, not because custom code is inherently superior.
Generic portfolio systems can produce polished pages quickly, but they rarely model contribution boundaries, publication states, evidence-controlled project narratives, related technical notes and reader-specific depth. Those requirements shaped the architecture.
| Option | Advantages | Limitations | Decision |
|---|---|---|---|
| Hosted portfolio builder | Fast initial setup and low initial development effort. | Recurring platform cost, limited information architecture, vendor constraints and weak support for deep engineering narratives. | Rejected. |
| Purchased theme | Reduced front-end effort and prebuilt layouts. | Generic structure, difficult long-term adaptation and likely mismatch with Stories and Notebook systems. | Rejected. |
| Custom application | Full control of information architecture, reusable content systems, visual identity and publication workflow. | Greater initial design and implementation effort, plus responsibility for maintenance. | Selected. |
The central decisions were treated as product-system choices: each one had to support the communication requirements, reduce maintenance load or preserve publication control.
| Decision | Why | Result |
|---|---|---|
| Next.js | Static and server-rendered editorial content, structured routing, metadata control and future expansion without manually maintaining unrelated pages. | Shared dynamic routes and reusable systems for Stories and Notebook entries. |
| React | Repeated interface patterns for media blocks, metadata, navigation, related content and interaction behaviour. | Design refinements can propagate through reusable components instead of being repeated by hand. |
| TypeScript | Structured metadata, publication states, technologies, images, links and narrative sections become harder to misuse as the project count grows. | More predictable interfaces and fewer content-shape errors. |
| Tailwind CSS | Rapid iteration for a one-person project, responsive states beside components and controlled spacing/design tokens. | Fast design iteration without a large disconnected stylesheet architecture. |
| Static/server-rendered editorial model | No current requirement for a database, accounts or runtime application backend. | Fast delivery and very low infrastructure cost. |
| Repository content rather than CMS | One principal publisher and every project requires evidence, contribution and IP review. | Content remains version-controlled, reviewable and aligned with the design system. |
| Separate Stories and Notebook systems | Commercial project narratives and ongoing technical investigations need different structures. | Stories demonstrate architecture, ownership and delivery; Notebook entries show investigation, experiments and evolving technical work. |
| Progressive disclosure | Different readers have radically different available attention. | Fast skim, structured overview and optional deep dive coexist on the same site. |
Operating cost was treated as a design constraint. The goal was not to avoid all tools, but to avoid infrastructure complexity that did not improve reader comprehension, editorial control or long-term maintainability.
Current direct website infrastructure cost is approximately US$8 per year under existing usage and hosting limits. Hosting currently remains within a no-cost tier. Paid theme, CMS subscription and database costs are zero for the current architecture.
ChatGPT is a broader research, editorial and development tool, approximately US$20 per month, and is not counted as pure website infrastructure cost. Free-tier conditions can change, so the cost statement is a current operating-state snapshot rather than a permanent guarantee.
Read less, understand more
Each page should answer the first question quickly before asking the reader for deeper attention.
Evidence before promotion
Claims are supported through project structure, decisions, images, source links or controlled narrative depth.
Multiple reading depths
One system supports skim, overview and deep technical inspection without duplicating content.
Responsive by default
Mobile, tablet and desktop layouts are treated as normal use cases, not a final cleanup pass.
Reusable implementation
Custom information architecture is implemented through shared routes, typed data and reusable components.
Public-safe technical depth
The site preserves technical credibility without publishing confidential implementation details.
The visual system was not applied after the engineering was complete. Content architecture, interface behaviour, imagery, typography and software structure were developed together as parts of the same product.
| Artistic and editorial workflow | Engineering and delivery workflow |
|---|---|
| Visual references | Requirements and constraints |
| Story hierarchy | Information architecture |
| Typography and colour | Design tokens and reusable components |
| Image and media treatment | Responsive asset handling |
| Narrative rhythm | Structured content schema |
| Interaction concepts | Component behaviour |
| Diagram composition | Technical accuracy |
| Editorial review | Lint, build and regression checks |
Defined the portfolio around product systems architecture, technical leadership and end-to-end product delivery.
Separated fast career navigation, flagship Engineering Stories and technical Notebook entries.
Developed the dark industrial interface, typography, copper hierarchy, motion and media language.
Built the portfolio with Next.js, React, TypeScript and Tailwind using reusable dynamic routes.
Published SmartRoller and used it to establish the reusable Engineering Stories design system.
Created a separate architecture for technical investigations, hardware development and engineering records.
Introduced evidence control, contribution boundaries, publication gating and IP-review workflows.
Expanding project content, diagrams and related-content connections while preserving the established system.
Features remain deferred unless they improve reader comprehension, editorial control or long-term maintainability.
Completed
Professional positioning, custom visual and interaction system, reusable website architecture, dynamic Engineering Stories, SmartRoller canonical story, Engineering Notebook architecture, evidence workflow and responsive layouts.
In progress
Additional flagship stories, deeper Notebook entries, original technical diagrams, related-content connections, accessibility refinement and performance refinement.
Intentionally deferred
Paid CMS, database-backed content, user accounts, unnecessary analytics complexity, high-maintenance effects, paid hosting infrastructure and features without a demonstrated reader or maintenance benefit.
Generative AI supports historical reconstruction, editorial organisation, implementation assistance and review. It does not originate the engineering projects, professional experience, design judgement or product direction.
Raghav remains the product owner, design authority, technical decision-maker, evidence controller and final reviewer. AI-assisted changes are kept inside repository governance: scoped prompts, diff review, lint, build and human acceptance.
Bradken
Led from the original field problem through commercial deployment, progressing SmartRoller from early feasibility into a rugged connected monitoring product for large mining excavators.
Bradken
Leading Bradken-side supplier delivery, hardware-system integration and field deployment as GET Vision progressed from an early vision prototype into a rugged, customer-deployed product for monitoring lost and worn mining GET.