Professional networking reimagined
Professional networking platform for job seekers and recruiters with real-time chat, job listings, and AI-powered matching.
Product system
Engaze connects professional networking, job applications, long-form publishing, and resume creation in one product. The strongest work is in the state transitions between those experiences—not isolated screens.
Professional networking
Discovery, follows, connections, requests, profiles, and conversations
Placement journey
Job discovery, eligibility, applications, interviews, and offers
Markdown editor
A reusable block engine for posts, blogs, chat, and rich content
Resume system
Editable templates, design controls, history, preview, and PDF output
Case study
A focused view of the product problems, system boundaries, and engineering decisions behind the work.
Product reality
A career platform has to preserve intent across more than a feed. A person can discover another professional, build a credible profile, open a job while signed out, complete missing information, attach a resume, answer screening questions, and return later to an application whose status has changed. Each hand-off crosses identity, relationship state, content, files, and backend policy.
My contribution
I worked across the Next.js and Flutter clients, Redux state, Express APIs, PostgreSQL models, object storage, and document-generation paths. I focused on making complex journeys continuous: modelling transitions explicitly, recovering interrupted work, reusing content infrastructure, and ensuring what a recruiter receives matches what the candidate created.
Engineering deep dives
Each story follows the user journey, its failure modes, and the decisions that made the system dependable.
Professional graph
Problem
Professional networking contains several independent states: following, being followed, sent and received connection requests, accepted connections, recommendations, and removal. Treating them as one boolean creates contradictory actions and stale cards across discovery, profile, and network screens.
Result
People can move predictably from discovery to a professional relationship and then into conversation. Requests, recommendations, follower lists, and accepted connections converge on the same relationship state after every action.
System path
Engineering decisions
Follows remain directional, while connections use a two-sided request lifecycle. The UI can therefore present the correct action without collapsing different professional relationships into one state.
Sent, received, viewed, accepted, declined, withdrawn, and removed states are handled deliberately, including moving records between pending and accepted collections.
Redux hydrates connections, followers, following, and recommendations together. Mutations update both the canonical lists and any recommendation cards that represent the same person.
Network rows connect directly to profiles and conversations, turning discovery into an actionable workflow instead of leaving it as a vanity count.
Placement lifecycle
Problem
Applying is not a single form submission. Jobs can have eligibility rules, required profile fields and social links, saved or uploaded resumes, screening questions, and authentication gates. Losing this work on a refresh or sign-in redirect breaks the highest-intent journey in the product.
Result
A candidate can move from job discovery through a validated application and continue into queries, interviews, offers, or withdrawal. Drafts and attachments survive normal interruptions without weakening account boundaries or leaving abandoned uploads behind.
System path
Engineering decisions
Public and institution-linked jobs share the experience while the backend applies the correct employer, student, and placement rules for each job context.
Seven-day drafts are namespaced per user and job. A short-lived same-tab marker allows a guest draft to continue after sign-in without exposing it to the next account on a shared browser.
Fresh resumes and screening attachments stay in the recoverable draft and upload during submission, avoiding orphaned objects when a candidate abandons the application.
A selected builder resume is rendered through the same template used by the editor, converted to PDF, and attached to the application alongside screening responses and required profile data.
Content infrastructure
Problem
Blogs, posts, comments, job descriptions, and messages need different editing constraints but must render the same stored content consistently. Separate editors would duplicate parsing, keyboard behaviour, uploads, previews, and display logic—and drift over time.
Result
One reusable block engine powers short and long-form experiences while Markdown remains the portable source format. Hosts can choose a compact composer or a full editor without rebuilding the editing model.
System path
Engineering decisions
Headings, paragraphs, lists, checklists, code, callouts, tables, polls, and media are explicit typed blocks that can be edited independently and converted back to Markdown.
A searchable slash menu, toolbar actions, shortcuts, selection-aware inline formatting, and predictable block creation keep rich editing fast without hiding the underlying format.
Images, video, files, resizing, previews, and upload callbacks use the same block contract. Each host decides whether media appears inline or at the end of a compact composer.
The same parser and display components render feeds, blogs, chat, comments, resumes, classroom posts, and job descriptions, keeping authored and published output aligned.
Document generation
Problem
A resume builder has three sources of complexity: structured career data, an editable visual layout, and a PDF that must preserve that layout. Template changes, section reordering, custom styles, and undo operations cannot corrupt the underlying resume or produce a different application artifact.
Result
Candidates can edit a structured resume visually, change its presentation without re-entering content, preview the result, and generate a multi-page PDF from the same rendering system used in the editor and application flow.
System path
Engineering decisions
Database-backed headers, sections, and items hold the content, while a React template registry controls its visual rendering. Switching templates changes presentation without rebuilding the resume.
Editable templates support inline fields, sortable sections and items, visibility controls, custom sections, and column assignment so the canvas itself becomes the primary editor.
Redux checkpoints track both content and customization through undo and redo, preventing a design change or section move from restoring only half of the resume state.
PDF generation captures the rendered resume at high resolution, filters editor-only controls, and slices long content across pages instead of maintaining a separate approximation of the template.
I can help take your next digital product from idea to production.
Get in Touch