How I built a modern SaaS for a 100-year-old skill (Architecture & UI Deep Dive)

Eklak — Wed, 03 Jun 2026 12:15:37 +0000

I recently launched Greggantic, an all-in-one ecosystem for mastering Gregg Shorthand.

If you aren't familiar with stenography, it's a century-old method of speed-writing used by court reporters and government officials to write up to 160 words per minute. But when I looked at how students were actually preparing for these high-stakes exams today, I was shocked. They were using analog tools: physical 20th-century books, pausing raw MP3 files, and manually guessing their stroke outlines.

As a Full-Stack Engineer and System Architect, I saw a massive opportunity to digitize an entirely offline workflow. Here is a breakdown of how I built it.

The Technical Architecture
To take this from a static learning process to a dynamic training environment, I had to build a few core systems:

The Oracle Dictionary: I built a smart search engine where users can type any English word and instantly retrieve the optimized shorthand stroke. This required structuring a highly searchable database mapped to complex SVG/image outputs, supporting UNIX-style syntax for suffix searches.

The Dictation Engine: A graded audio hub that scales from 60 to 160 WPM. Delivering hundreds of hours of high-quality audio seamlessly without buffering issues meant leveraging solid cloud infrastructure and CDN caching on AWS.

Standardized Skill Evaluation: We built a simulated exam environment that tests typing speed, grades transcription accuracy, and tracks WPM growth over time.

The UI/UX: Making "Boring" Look Premium
Government exam prep platforms usually look like they were built in 2003. I wanted Greggantic to feel like a premium, modern SaaS.

I leaned heavily into a brutalist minimalist aesthetic inspired by platforms like Linear. To make the interface feel incredibly fluid and alive, I utilized a specific stack for the frontend interactions:

GSAP & Framer Motion: For micro-interactions, page transitions, and bringing the shorthand strokes to life on the screen.

Lenis: To implement smooth scrolling, which makes navigating the massive dictation libraries and long study materials feel effortless.

When you take an audience that is used to messy, cluttered government websites and give them a sleek, high-performance UI, you build instant trust.

The Result
We are currently sitting at 499+ highly active students on the core platform, spread across 17 countries, with a broader community of over 12,400+ aspirants.

Building for a micro-niche that the tech world has completely ignored is incredibly rewarding. You aren't just fighting for incremental improvements over a competitor; you are introducing software to people who have never had a tool built specifically for them.

If you are interested in the UI or the platform itself, check it out here: greggantic.com

Would love to hear from other devs building micro-SaaS platforms. What is your go-to stack for handling complex media delivery and smooth UI? Let's chat in the comments!

DSA vs Development: The Split Nobody Talks About Honestly

Eklak — Mon, 16 Mar 2026 18:55:44 +0000

Every developer is grinding both. But nobody tells you how much of each, or why the answer depends on where you actually want to go.

Let Me Start With Something Real

I've been there. Three tabs open, one is a LeetCode problem, one is a half-finished API, and a YouTube video where some guy says "master DSA first, everything else can wait." And another video right below it says the exact opposite.
Nobody was giving me a straight answer. So I figured it out the hard way. And this is what I wish someone had told me on day one.

First, What DSA Actually Is (Beyond the Interview Hype)

DSA is not just interview prep. That's the surface-level take.
At its core, DSA is how you think about problems. It trains your brain to see patterns, recursion, breaking a problem into subproblems, thinking about time and space tradeoffs. That mental model does not disappear when you close LeetCode. It shows up when you're designing a database query, when you're debugging a slow API, when you're architecting a feature under pressure.
Think of it this way: DSA is a thinking gym. Development is the actual game. You don't skip the gym. But you also don't live in it.
The problem is most developers treat it as one or the other. Either they DSA grind for months and have zero real projects, or they build cool stuff but can't pass a technical screen at a company they actually want to join.
The answer is a split, and the split depends entirely on your goal.

The Two Paths, Two Different Splits

Path 1: MNC / FAANG / Service Based Company
Split: 60% DSA, 40% Development
These companies have structured hiring pipelines with DSA rounds as gatekeepers. You cannot skip the game, so you have to actually master it. The filter exists not because binary search trees show up in daily work, but because it tells them you can handle complexity and pressure.
Path 2: Startup / Product Company
Split: 80% Development, 20% DSA
Startups move fast. They want builders. They want someone who can own a feature, ship it, and not break everything. But even they want to see that you can think. They just won't ask you to invert a binary tree to test it. A few basic problem-solving questions, and they're checking whether you can reason clearly, not whether you've memorized algorithms.

Why This Split Actually Makes Sense

At a FAANG or large service company, you are one of thousands of applicants. They need a filter. DSA is that filter. So if that's your target, you don't get to treat DSA as optional. It is the price of entry, at least until you get through the door.
At a startup, the question is completely different. They are not asking "can you solve hard algorithmic puzzles?" They are asking "can you ship? Can you think? Can you own something end to end?" Your GitHub matters more than your LeetCode streak here.
But here's the part most people miss about startups: they still throw in one or two problem-solving questions. Not to test your algorithms knowledge, just to see if you can think. There is a difference. They don't care if your solution is perfectly optimized. They care if you approached it logically and communicated your thinking clearly.

The Real Mistake Most Developers Make

The mistake is not choosing the wrong split. The mistake is not choosing at all.
Most developers float in the middle, doing a bit of DSA, building a bit, finishing nothing, mastering nothing. Six months later they are in the same place, just more frustrated.
You don't need to choose DSA or development forever. You need to choose your current focus based on your next goal.
This shift in thinking changes everything. Your time allocation is not permanent. It moves with where you're headed.
Going for campus placements in three months? Go 60/40 toward DSA. Got a startup role and want to grow there? Flip it, go deep on building real systems. Transitioning into AI engineering or a niche domain? Development and system design take over, DSA becomes maintenance mode.
How to Actually Structure Your Week

If you're targeting MNCs or FAANG:

Dedicate your focused morning hours to DSA when your brain is fresh. Aim for two to three problems a day, not ten. Quality reps beat volume every time. In the evening, work on a project that shows system design sense. It doesn't have to be complex. A clean REST API with proper auth, a frontend that connects to it, deployed somewhere real. That's enough.
If you're targeting startups:
Build something people can see and interact with. Spend the bulk of your time on one solid project you can talk about deeply, the architecture decisions, the tradeoffs, how you would scale it. Reserve one day a week for DSA just to keep the problem-solving muscle warm.
The rule that applies to both:
Never have zero proof of work. A LeetCode profile with no GitHub is a red flag. A GitHub with nothing working is also a red flag. Have one real project, one deployed thing, one proof that you can build and not just read about building.

My Honest Take on DSA

DSA gets a bad reputation from developers who only ever see it as a hiring hoop to jump through. And I get that frustration. The "invert this tree" question does feel disconnected from building a real product.
But here's what changed for me. When I stopped thinking of DSA as interview prep and started thinking of it as learning how to think, the resistance went away. Recursion taught me how to design recursive data flows. Hash maps made me think about lookup performance in my APIs. Graph traversal made system dependencies make more sense.
The skill compounds. The payoff is just delayed and subtle, which is why so many developers quit before they feel it.
The developers who are dangerous three years from now are the ones who can build things and explain every technical decision they made. DSA gives you the vocabulary. Development gives you the proof.

DEV Community: Eklak

How I built a modern SaaS for a 100-year-old skill (Architecture & UI Deep Dive)

DSA vs Development: The Split Nobody Talks About Honestly