Software Engineer · SDE-2
01 / Work
My first project at GYTWorkz

Intro.vc

Frontend Engineering · Product Development · Startup Discovery

A startup discovery platform where product, networking, and frontend engineering came together.

02The product

The product

Intro.vc was a platform built around startup discovery and connections between startups, investors, accelerators, and incubators.

01 Startups02 Investors03 Accelerators04 Incubators
The product included
  • Startup profiles
  • Startup discovery
  • Pitch videos
  • Connections
  • Messaging
  • Community
  • Posts and interactions
  • Dashboards

My work was mainly frontend engineering and product development — turning requirements into interfaces and user flows across these parts of the product.

03Where it started

Where professional engineering started for me

Intro.vc was my first project at GYTWorkz. It was an early opportunity to work on a real product, understand requirements, build user-facing experiences, and see how decisions made in code shape the product people actually use.

  1. 01 — This pageIntro.vcProduct · Frontend
  2. 02SafetyConnectReal-time data · Visualization
  3. 03Network Automation PlatformSystems · Integration
04What I worked on

Where the frontend work sat.

  1. 01

    Startup profiles

    Interfaces for presenting startup information and helping users understand a company quickly.

  2. 02

    Discovery

    Frontend experiences for browsing and discovering startups.

  3. 03

    Pitch videos

    Interfaces for presenting startup pitch content.

  4. 04

    Connections

    User flows around connecting people within the platform.

  5. 05

    Messaging

    Frontend experiences for communication between users.

  6. 06

    Community

    Interfaces supporting interaction and participation across the platform.

05Product flow

How someone moved through the product.

Conceptual product journey · not an architecture diagram

07Frontend engineering

Turning requirements into interfaces

The work sat somewhere between product requirements and implementation — understanding what a flow needed to do, figuring out how it should work for the user, and then building it.

The interesting part wasn’t just building individual screens. It was making the different pieces of the product work together as a coherent experience.

  1. 01Requirement
  2. 02User flow
  3. 03Interface
  4. 04Implementation
05Problems I solved

Problems I solved

Most of the interesting frontend work on Intro.vc came from flows that had more states than they first appeared to.

P.01

Multi-step startup onboarding

Startup onboarding collected a lot of information: company details, team members, target investors, pitch decks, logos and pitch videos.

Problem

Putting everything into one large form would make the frontend difficult to manage and make validation and corrections harder.

Approach

Split the onboarding into multiple steps and managed each part independently.

  • Step navigation
  • Field validation
  • Character limits
  • Team member inputs
  • URL validation
  • File validation
  • Upload states
  • Correction states
  1. Startup info
  2. Target investors
  3. Pitch
  4. Review
  5. Correct / resubmit
Result

The frontend could handle a complex registration workflow without turning it into one large form, while still letting users correct and resubmit their information.

P.02

Recording pitch videos in the browser

Users could record their pitch directly from the browser.

Problem

Browser recording introduced more states than a normal file upload: camera permissions, media streams, recording, start and stop, preview, reset, confirmation and upload.

Approach

Built the recording flow around the browser media APIs and managed the recording state in the frontend.

  • Camera permissions
  • Media streams
  • Start / stop
  • Preview
  • Reset
  • Confirmation
  1. Camera
  2. Record
  3. Preview
  4. Confirm
  5. Upload
Result

Users could record and submit their pitch inside Intro.vc without preparing a video somewhere else first.

P.03

Different users needed different experiences

Intro.vc had separate frontend experiences for startups and entrepreneurs, accelerators and incubators, and admins.

Problem

Each user type had different workflows and needed different interfaces.

Approach

Built each experience around the responsibilities of that role.

Startups
  1. Profile
  2. Discover
  3. Pitch
  4. Connect
  5. Communicate
Accelerators
  1. Manage
  2. Discover
  3. Interact
Admins
  1. Review
  2. Manage
  3. Filter
  4. Analyze
  5. Export
Result

The same platform could support different workflows without forcing every type of user into the same interface.

P.04

Authentication and API requests

Problem

Authentication and request handling were repeated concerns across many screens, and expired sessions needed handling without every screen dealing with it separately.

Approach

Used a centralized HTTP layer to attach tokens, send requests, detect 401 responses, refresh authentication and retry the original request.

  1. Frontend
  2. Authenticated HTTP client
  3. API
  1. 401
  2. Refresh token
  3. Retry request
Result

Authentication and retry behavior stayed in one place instead of being duplicated across screens.

P.05

Admin data management

Problem

The admin application worked with large amounts of structured data across startups, investors, products and requests.

Approach

Used reusable data-management patterns across admin areas.

  • Tables
  • Filtering
  • Sorting
  • Pagination
  • Charts
  • CSV export
Result

Admin areas could share consistent data interfaces instead of implementing every table from scratch.

06 — Technical territory
  • React
  • Redux
  • React Router
  • Axios
  • Material UI
  • Ant Design
  • styled-components
  • React Table
  • Video.js
  • RecordRTC
  • Chart.js
07What stayed with me

What stayed with me

  1. 01

    Understand the requirement

    Before thinking about the component.

  2. 02

    Think in flows

    A screen is part of something bigger.

  3. 03

    Build for the product

    Frontend work should connect back to what the user is actually trying to do.

← Back toWorkNext →SafetyConnect