This was one of my first experiences where I got the opportunity to take a project from 0 to 1 — right from idea to execution. I’ve been thinking to document my experience so here I am trying to do so, sharing the kinds of tasks I worked on and what I learned throughout the process.
There’s a lot of content online about how to land an internship or job, but very little that talks about what actually happens after you get one — what kind of work you do daily, how teams operate, and how a product evolves internally. So this is my small attempt to shed light on that part of the journey.
To give some context: all of my internship experiences so far have been with early-stage startups. I haven’t worked at any of the big tech companies or growth-stage startups yet. At my current startup, I joined as a full-stack engineer and was their very first hire.
In early-stage startups, founders usually have a clear vision of what they want to build, and the initial weeks are mostly spent by the engineering team trying to deeply understand that vision and translate it into a product roadmap. I won’t lie being a college student, I was pretty nervous at first. But I’m incredibly grateful to the team for trusting me to take on such a big responsibility.
Due to confidentiality, I can’t reveal the exact platform we’re building, but I can definitely talk about the technical challenges and learnings.
Choosing the Tech Stack: The first step was deciding the tech stack. Since our team was comfortable with JavaScript, we chose Next.js to build the MVP. It’s fast to work with, production-ready, and comes with a lot of features out of the box. Alongside, we used React Query for data fetching, Zod for schema validation, and MongoDB as our database.
As the product grew, we had to integrate a number of services — like Resend for transactional emails, Cloudinary for media uploads, cron jobs to automate tasks at scheduled intervals, AI feature integrations by using OpenAI and Gemini API, a background worker for long queue-based operations and PostHog for product analytics. For our initial MVP deployment, we went with Vercel because of its simplicity and speed of setup — especially helpful for teams trying to move fast. However, as we prepare to scale and need more control over resources and infrastructure, we’re exploring options like DigitalOcean and AWS for future deployments.
One of the most challenging parts was working with the Instagram APIs via Meta’s Graph API, since our product falls under the creator economy space. We had to dig deep into the documentation to understand the complete flow — especially how to retrieve insights from creator accounts. One frustrating part was that, to get detailed Instagram insights, users also need to have a connected Facebook account and a Facebook Page, which complicates things from a UX perspective.
A huge chunk of my time went into figuring out Meta’s API integration — not just implementing it, but also handling the nuances of their app review process, which is necessary to take your app from development to live mode. I’d say the experience with Meta APIs can vary a lot depending on your use case, but for us, it was definitely one of the more time-consuming parts. I came across a Reddit post that echoed many of our struggles — Super insightful Reddit post .
Once the integrations were done, it became a matter of putting all the pieces together to make the app functional.
Lately, I’ve been reading more about scaling products — how you go from supporting 100 users to 1,000 and beyond to 5,000+. I’ve been following solo developers and indie hackers on Twitter, and Threads and a common theme is how quickly things start to break once real user traffic picks up.
It made me realize the real value of senior engineers. Today, with the rise of AI tools and frameworks, even non-engineers can put together a basic CRUD app. But building resilient, scalable, and production-grade systems — that’s still a tough problem, and that’s where experience truly shines.
One of the biggest takeaways from this experience was the importance of maintaining code quality, even when you’re building fast. At early-stage startups, technical debt is almost inevitable. When you’re part of a small team (in our case, just 2–3 developers), and you’re trying to ship quickly, it’s easy to compromise on things like proper folder structure, comments, and clean architecture. But that debt adds up quickly.
I learned how crucial it is to document your code well, maintain a consistent folder structure, and leave clear, meaningful comments. It massively reduces onboarding time and avoids confusion when new developers join the team. We also made sure to handle some foundational practices early on — like implementing caching for frequently accessed data using in-memory stores and browser-level caching where possible, and setting up basic rate limiting on our API endpoints to avoid misuse and stay within third-party API limits.
I’m now starting to explore concepts like observability, error monitoring, and performance tracking so we can better understand what’s happening in production. These might seem like small things when you’re moving fast, but they make a huge difference when you want to scale confidently.
Also, keep in mind that when you join a startup, you’re not just hired to complete tasks. You’re expected to think beyond code — to understand the business, give product input, shape the culture, and take real ownership. You’re part of the core team, and your decisions can impact the entire company.
That level of involvement needs focus and context — something you can’t give if you’re juggling multiple jobs. If it’s just about shipping features, founders might as well outsource to an agency. It’s cheaper and less complicated.
This experience gave me a real-world look into building products from the ground up, and I couldn’t have asked for a better learning experience. The challenges were real, but so was the growth. I was also involved in talking to users during the testing stages, which helped me understand how crucial user feedback is when shaping a product. At the end of the day, building a product is all about customer satisfaction — and that means constantly listening, iterating, and improving. It’s completely normal to feel frustrated at times, especially when you run into unexpected bugs or things don’t work as planned. But that’s part of the process. The key is to stay focused on the problem, keep debugging, and push through until you solve it. That’s where the real learning happens.
Also, I mostly write blogs on medium. If you want to read more then here is my medium account link feel free to check out :) https://medium.com/@awdhesh1700
Update: By the way, as I mentioned, I'm currently building Snatch at Slate — Snatch helps emerging creators & influencers to connect with brands that fit. Build your press kit in minutes, share it anywhere, and let brands see what you bring to the table. It's a simple, real-time press kit builder along with a creator dashboard, designed for Instagram creators and micro‑influencers. Just connect your account, pick your best posts and collabs, and we’ll turn it into a clean, professional media kit — no design tools needed.