Things start breaking once you actually start building

LEELA AKASH MARIDI — Mon, 30 Mar 2026 05:09:05 +0000

Phase 1 was mostly thinking.
Phase 2 is where things started getting real.

When you’re planning, everything looks clean.
In your head, the system makes sense. The flow works.
Nothing crashes. Nothing conflicts.

Then you actually start building.

And suddenly things don’t fit the way you expected.
Something small takes hours. Something you thought would be hard gets done in 20 minutes. No pattern, no logic.

I’ve been spending most of my time just figuring things out step by step.
Not big breakthroughs, just small progress every day.

One thing I’ve realised is this —
you don’t build in a straight line.

You build, then you go back and change something.
Then that change breaks something else.
Then you fix that and realise the first version was actually better.

It’s a loop.

Also, working solo on the code means every decision matters more.
There’s no “we’ll fix it later” or “someone else will handle it”.
If I mess up the structure now, I’ll pay for it later.

So a lot of time is going into keeping things simple.
Not perfect. Just simple enough to move forward.

We’re still not sharing anything about the project yet.
But yeah, it’s no longer just an idea. It’s actually turning into something.

Phase 2 deadline is coming up.
Let’s see how much we can get done before that.

Akash
Team VAARANASI
Guidewire DEVTrails 2026

Our first hackathon where we actually had to think like a startup

LEELA AKASH MARIDI — Mon, 16 Mar 2026 18:42:01 +0000

I am a third year CSE student and last week someone handed me
a problem statement and said build a startup in 6 weeks.

Not a college project. Not an assignment. An actual product
that solves an actual problem for actual people.

That was two weeks ago. And honestly those two weeks taught
me more than the last two semesters combined.

The first few days were just reading and rereading the problem.
We kept thinking we understood it and then realising we did not.
There is a big difference between reading a problem statement
and actually understanding the people you are building for.

We went back to basics. Who uses this? What do they earn?
What does a bad day look like for them? What would actually
help them versus what just sounds good in a pitch?

That took almost a full week. And I think that was the most
important week.

Building something is the easy part honestly. Figuring out
what to build and why is the hard part. Most teams skip that
and go straight to coding. We almost did too.

Week two was cleaner. Once we knew what we were building and
why, everything else fell into place faster. Tech stack,
architecture, screens, all of it moved quickly once the
thinking was done.

I am the only one coding on our team of four. The rest are
handling research, documentation and testing. That means
every decision I make has to be something I can actually build
alone in the time we have. No overengineering. No fancy things
that look good on paper but take three weeks to build.

Scope creep is real and it will kill your submission faster
than anything else.

Five days left for Phase 1. We have to submit our GitHub repo,
a README and a two minute video. The video is the thing I am
most nervous about. Writing is easier than talking to a camera
apparently.

If you are also doing DEVTrails or any hackathon right now
my only advice is this. Spend more time on the problem than
the solution. The solution changes. The problem does not.

Will write again after Phase 1 results.

Akash
Team VAARANASI
Guidewire DEVTrails 2026

DEV Community: LEELA AKASH MARIDI

Things start breaking once you actually start building

Our first hackathon where we actually had to think like a startup