@lnsekhon

worked on the frontend UI, component structure, and backend Gemini integration for Hatchway. I started by setting up the dark-mode landing page with teal gradients, breaking the layout into modular components for the navbar, hero section, and project overview. On the “Try It” page, I built the main product form with input fields for the App Name, Short Description, and Closest Large City, alongside a dedicated Results container underneath. To handle the dynamic logic, I connected the form state to a backend route that sends the product payload over to the Google Gemini API. When you hit “Generate Matches,” the button triggers an asynchronous loading state, passes the project data to Gemini, and renders a tailored list of VC conferences and pitch opportunities right inside the results view.

added the main “Competitive Programming Helper” text on entry of project. pretty cool ig

I got you. Let’s rewrite that MVC update so it actually sounds like a human who writes code wrote it, while keeping all the em dashes and corporate buzzwords out of the picture.In this build, I finally finished up all the Models, Views, and Controllers for the main app. Having the full MVC setup wired together means data is actually moving cleanly between the database, backend logic, and user screens without things breaking.Now that all the main routes and pages are functional instead of just sitting there as blank placeholders, the core structure of the project is pretty much locked in. From here, I can shift focus to polishing up the UI, catching weird edge cases, and running real end-to-end tests to make sure everything holds up.

In this update, I built the backend Ruby server and set up the initial database schema. First, I created the authentication table to handle login functionality, then implemented route protection around the /dashboard endpoint. Unauthenticated users attempting to access protected routes are redirected back to the login page, while authenticated users are directed to the specific view assigned to their role.Second, I built out database tables for the four main user types: Students, Guidance Counselors, Teachers, and Admissions Staff. Establishing these base models and access controls sets up the foundation needed to build out role-specific permissions and workflows in upcoming updates.

I created a small animation for the openning of the app, scrolling up our two current pages with text that prompts the user to click any key to continue into the app. The text also flashes which is pretty cool and I thought was fun to implement!

In this update, I built the initial framework for Better Studentrecs. This version sets up the core routing and authentication layout, featuring a simple login interface alongside dedicated placeholder pages for each user type.

On the backend, I implemented basic role-based authorization to handle permissions across different accounts. However, the business logic is still in progress; the system is not yet hooked up to application status tracking, guidance counselor management tools, or teacher recommendation reports. These foundational updates establish the layout and access rules needed before connecting the dynamic data models in upcoming builds.

In this update, I built the initial framework for Better Studentrecs. This version sets up the core routing and authentication layout, featuring a simple login interface alongside dedicated placeholder pages for each user type.

On the backend, I implemented basic role-based authorization to handle permissions across different accounts. However, the business logic is still in progress; the system is not yet hooked up to application status tracking, guidance counselor management tools, or teacher recommendation reports. These foundational updates establish the layout and access rules needed before connecting the dynamic data models in upcoming builds.

In this build, I added the problem fetcher and the contest fetcher to Competitive Programming Helper. Both systems connect with platforms like Codeforces and AtCoder. Without these features, the app was just a static text editor that required copying and pasting test cases manually. Fetching data directly turns it into an automated workflow tool.functionality-wise, the problem fetcher takes a problem ID from Codeforces, extracts the sample test cases, and runs the user’s local code against them to check the output. At the same time, the contest fetcher uses a web scraper to pull upcoming competition schedules from both Codeforces and AtCoder into a single list.Together, these features build out the core data pipeline for the app, handling local test execution and schedule tracking in one place.

In this build, I added the problem fetcher and the contest fetcher to Competitive Programming Helper. Both systems connect with platforms like Codeforces and AtCoder. Without these features, the app was just a static text editor that required copying and pasting test cases manually. Fetching data directly turns it into an automated workflow tool.functionality-wise, the problem fetcher takes a problem ID from Codeforces, extracts the sample test cases, and runs the user’s local code against them to check the output. At the same time, the contest fetcher uses a web scraper to pull upcoming competition schedules from both Codeforces and AtCoder into a single list.Together, these features build out the core data pipeline for the app, handling local test execution and schedule tracking in one place.