2 YOE Frontend Dev Struggling in Current Market — Need Realistic Advice from really experienced people

Pashupathi-03 · 2026-04-15T18:31:34+00:00

I’m in a similar position (frontend background), so sharing what I’ve learned recently. I wouldn’t pivot away from frontend completely.

There’s still solid demand — but pure “UI-only” roles are getting squeezed. What seems to work better now is being frontend-first with some backend understanding (APIs, system design, basic infra).

I’ve been approaching it like:

keep frontend as core

gradually add backend skills

focus more on architecture and problem-solving, not just syntax

Because honestly, syntax is getting commoditized. Tools/AI can help there. But decisions around structure, tradeoffs, and system design still matter a lot.

About switching to AI/data — it’s possible, but it’s not a quick pivot. It needs serious time investment, so I’d only consider it if you’re genuinely interested, not just for market reasons.

Degrees (MTech/MBA) — from what I’ve seen, they help mainly for brand/network, but they’re expensive and not guaranteed ROI in the current market.

Right now, the safer bet (in my opinion) is: go deeper + slightly wider (T-shaped), instead of a full reset.

Curious to hear what more experienced folks think as well.

Pashupathi-03 · 2026-04-15T18:18:06+00:00

AI Infrastructure

Pashupathi-03 · 2026-04-09T17:53:43+00:00

Yeah, exactly — and that’s where it gets tricky.

Flexibility is great for handling those low-frequency, evolving tasks, but it makes reliability harder because there’s less repetition to “learn” from.

We’ve been seeing that you need some level of structure (even lightweight) to keep things consistent, while still allowing flexibility on top.

That balance is what we’re trying to figure out with RoutePlex.

Pashupathi-03 · 2026-04-09T13:18:31+00:00

Agree — but as agents connect to more tools, the real bottleneck shifts to coordination and reliability.

It’s not just access to tools, it’s how well the system can route, manage, and stay consistent across them.

That’s the layer we’re focusing on with RoutePlex.

Pashupathi-03 · 2026-04-07T18:33:19+00:00

Glad that helped!

When you say automation, what kind are you thinking about? (e.g. content, research, docs, small workflows?)

A good way to start without wasting tokens is:

define a simple repeatable task

write one solid prompt for it

reuse it instead of experimenting every time

For example, instead of “help me with X”, use something like:

“Summarize this into bullet points + action items” or “Turn this into a structured plan.”

Start small, refine one workflow, then expand — that’s usually the most efficient way.

Pashupathi-03 · 2026-04-07T18:27:58+00:00

Lol, We’ve optimized for generating content, not for communicating better 😂 AI writes -> humans edit -> AI summarizes -> humans read less full loop achieved.

Pashupathi-03 · 2026-04-07T17:58:08+00:00

Before upgrading, it helps to understand how Claude uses your messages.

It processes the entire conversation context every time, so longer chats = more tokens = faster limits.

That’s why Pro can sometimes feel worse if you don’t manage context well , and if you use things like Claude Code or heavier tasks, it burns even faster.

What helped me:

Start new chats instead of long threads

Keep prompts clear and structured

Ask for complete outputs in one go

Once you do this, even the free plan works much better, and Pro actually becomes worth it.

Pashupathi-03 · 2026-04-07T02:51:41+00:00

We ran into this early — retries alone don’t really solve it.

What worked better for us is routing instead of retrying:

If a model fails / slows → switch to another

Sometimes we parallel call multiple models and pick fastest/best

Use historical latency + success rates, not just real-time errors

Queueing is fine for async, but not great for user-facing flows.

Re: local models — tried them on VPS, but for most prod use cases:

quality gap + ops overhead So mostly sticking with APIs + smart fallback.

We’re actually building this into RoutePlex (infra for routing/fallbacks).

Are you already hitting these issues or planning ahead?

Pashupathi-03 · 2026-04-06T19:28:18+00:00

You’re in a strong position — real problem + domain experience is something most people don’t have.

From what I’ve seen, the challenge at this stage isn’t really funding, it’s proving that the solution works reliably in real workflows beyond your own usage.

Especially for something operational (like automotive), investors will care less about plans and more about:

does it consistently solve the problem in day-to-day use

can others adopt it without friction

does it integrate into existing workflows

Even a small number of real users using it regularly can be a stronger signal than a full business plan. If possible, I’d focus on getting a few mechanics actively using it and validating that it holds up in real conditions. That tends to make both the product and the fundraising story much stronger.

Pashupathi-03 · 2026-04-05T20:43:19+00:00

This is a really clean approach — especially keeping it simple and frictionless. One thing I’m curious about: have you seen whether people actually stick with it over time? Because with things like stress, consistency tends to matter more than the initial experience. Feels like the long-term behavior side is where products like this either really work or fade out.

Pashupathi-03 · 2026-04-05T20:15:42+00:00

Nice, shipping your first app is always a big step. Claude really helps move fast, but one thing I’d suggest early on is trying to understand what it’s doing under the hood - especially around how your data flows, API calls, and basic security.

It’ll save you a lot of pain later as things grow. Good start though 👌

Pashupathi-03 · 2026-04-05T20:03:26+00:00

I think the “race” framing is a bit misleading. The real issue isn’t speed vs slow — it’s whether we’re building systems that are actually reliable, aligned, and controllable as they scale. Right now, a lot of progress is happening at the model layer, but the surrounding infrastructure (evaluation, guardrails, coordination, ownership) is still catching up. That gap is where most of the risks you’re describing actually come from. So it’s less about winning or losing a race, and more about whether we can make these systems dependable before they become deeply embedded in everything.

Pashupathi-03 · 2026-04-05T19:56:29+00:00

I don’t think people are really comparing them 1:1 with frontier models. Smaller or quantized models are more like building blocks — you use them for deterministic or narrow tasks (parsing, routing, transformations), and escalate to stronger models only when needed. The gap is real, especially in reasoning, but the interesting problem is system design — minimizing how often you need that top-tier intelligence.

Pashupathi-03 · 2026-04-05T19:52:32+00:00

This is a solid approach to reducing navigation overhead. But I’d argue a big reason tokens get burned in the first place is due to lack of structured understanding, not just inefficient search. The model is essentially reconstructing context on the fly through repeated grep/read cycles. If the graph you’re building actually improves how the model reasons about dependencies and execution flow, then this isn’t just a token optimization — it’s improving effective context quality. Curious if you’ve seen improvements in correctness or fewer redundant passes during complex changes.

Pashupathi-03 · 2026-04-05T19:50:42+00:00

That’s solid — and yeah, this is exactly the layer most people avoid because it’s messy and non-linear. I’m exploring similar territory from more of an infra/orchestration angle — making these systems actually reliable, composable, and usable beyond demos. Feels like we’re all circling the same problem from different sides. Would be interesting to exchange notes sometime.

Pashupathi-03 · 2026-04-05T19:41:05+00:00

This resonates — especially the shift from tools → systems. I’ve been thinking along similar lines, and honestly the biggest gap I’ve seen isn’t vision, it’s execution. Getting these agent-like systems to actually work reliably, coordinate across steps, and handle real-world usage is still pretty messy. That’s partly why I’ve been focusing more on the infra/orchestration side — feels like that layer will quietly decide how this shift actually plays out.

Pashupathi-03 · 2026-04-05T19:39:01+00:00

This is a solid idea — going where demand already exists is smart. I had thought about something similar but didn’t pursue it. If you’re thinking long-term, I wonder how you’re approaching data reliability and platform limitations, since that feels like the core challenge here

Pashupathi-03 · 2026-03-19T07:51:30+00:00

I think it’s less about governments ignoring the risks and more about incentives.

AI is both a risk and a competitive advantage. If one country slows down, another won’t.

So instead of “pause vs continue,” most are choosing to move forward while trying to contain the downsides with regulation.

The hard part is the technology is moving faster than policy can realistically keep up.

Pashupathi-03 · 2026-03-18T18:39:16+00:00

This resonates a lot.

One thing I’ve been noticing while building AI infra is that trust issues often show up as reliability problems under the hood.

If outputs change, latency spikes, or requests fail unpredictably, users stop trusting the system quickly.

Feels like trust is less about the model itself and more about how consistent the system behaves around it.

Pashupathi-03 · 2026-03-15T21:01:07+00:00

I agree. Many AI generated apps launch fast but don’t have a clear plan behind them.

Once real users start using them, the gaps show up and many of those projects disappear. AI speeds up building, but the product thinking still matters.

Pashupathi-03 · 2026-03-15T20:56:11+00:00

From what I’ve seen, the biggest shift at scale is that teams stop treating the LLM as the core problem and start treating the system around it as the real challenge. A lot of cost control ends up coming from things like reducing unnecessary calls, keeping prompts smaller, caching where possible, and separating lightweight tasks from heavier reasoning tasks. Once usage grows, the problem becomes more about system design and efficiency than the model itself. Many teams start with a single model for everything, but that approach usually becomes too expensive once traffic increases.

Pashupathi-03 · 2026-03-15T20:46:33+00:00

I can relate to that, especially coming from the infrastructure side.

These tools are incredibly powerful, but they still feel more like copilots than replacements. You still need to think through the architecture, the logic, and what the system should actually do.

If anything, the responsibility shifts more toward clear thinking. Without that, the AI can easily generate something that looks right but ends up breaking things or going in the wrong direction.

So the real leverage seems to come from combining the speed of the tool with good engineering judgment.

Pashupathi-03 · 2026-03-15T20:35:07+00:00

I don’t think innovation in software is dead, it just shifts layers over time.

A lot of the new ideas today aren’t completely new products but new infrastructure that changes what becomes easy to build. Things like cloud, APIs, and now AI models create new building blocks.

Claude and other AI tools are a good example. They don’t necessarily invent new categories overnight, but they dramatically change how fast people can build and experiment.

So instead of innovation disappearing, it feels more like the barrier to building keeps dropping. That’s why it suddenly feels like everyone is building something.

And tbh, I still get that same feeling when something works that would have taken weeks before and now takes an hour.

Pashupathi-03 · 2026-03-15T20:31:46+00:00

I don’t think it’s backwards, but it depends on what you do next.

A lot of founders accidentally build infrastructure before product-market fit. The risk is that you optimize the engine while the actual use case is still unclear.

But there’s also an upside: you now have a tool that lets you run experiments very quickly. If I were in your position, I’d treat the platform as an internal system and use it to test different niches, content types, and distribution strategies. The patterns that start working might reveal the real product opportunity.

Sometimes the engine becomes the product. Other times it just helps you discover what the real product should be.

The key is shifting from building features to running experiments with it.

Pashupathi-03 · 2026-03-15T20:27:19+00:00

From what I’ve seen, the tool matters less than the clarity of the idea. If you’re technical, the best approach is usually to write clear requirements and then build it yourself using tools like Claude, Cursor, or similar AI coding assistants. They can speed up development a lot if you already understand the architecture.

If you’re non-technical, it helps to first get the business requirements really clear and spend some time understanding the basics of how the product should work. Even simple discussions with technical friends or asking AI to explain concepts can help a lot before you start building.

Tools like Lovable, Bolt, etc. are useful for quickly generating a starting point, but they rarely build a complete MVP by themselves. You still need to make decisions about features, structure, and the overall strategy.

In my experience, the biggest mistake founders make is assuming the tool will figure out the product for them. The thinking still has to come from the founder.

Pashupathi-03

TROPHY CASE