Ask HN: Can I realistically make an app as a junior dev?

Don't add complexity until is really necessary, I use this principle in my daily work as software engineer and it's very usefull, build what you need now not in a year, you cannot predict how your app evolve in long term, especially if you are a Junior Dev, there will be time to steer or scale in the future direction, first validate, create community around app and why not make money (?), and after this, scale and add complexity :)

Yes, keep things as simple as possible. Keep asking questions; don't solve reach for complex solutions unless you've confidently drilled down on the problem

Thank you!! This is really good to know.

>Can I realistically make an app as a junior dev?

Most senior devs can't make a complete app from scratch - and that's not a bad thing. Like most disciplines we specialize, and so a "full stack senior dev" ends up being very good at a small slice of the whole software production pipeline. Even with LLMs, it takes a lot of effort and iteration before even a small product can reasonably serve a broad group of people.

Don't worry too much about "architecture" - there's never a perfect architecture. I think what you're describing is judgement. Senior devs aren't born with good judgement, nor do they acquire it by solely consuming content (books, videos, posts). The most successful pattern I've seen is: try your best, consider how difficult it would be to change things later, and favour simple solutions in general.

Since you're using this project to learn, I would advise you to use Claude Code with intention. You should read code 10x more than you write code (it's okay if Claude does the writing). Try to avoid asking Claude to explain the code to you. It's nice if you need a quick verification, but generally just try to find things out for yourself.

You're on the right track. Good luck!

Thank you!! This was really helpful and informative.

> Can I realistically make an app as a junior dev?

You will only find out if you try it.

I love this mindset

Looks to be something like a 3-tier app plus cache... nice. And the chosen tech stack are industry mainstays, so your time will not be wasted. I see some good points already commented, I will try not to be too repetitive. Keep things as simple and lean as possible to begin with, then add complexity when needed. Not before.

Claude and other LLMs are great for content generation and are to be embraced but not trusted. Don't let Claude or any of its siblings run you around in circles.

Finally, this one really helped me; don't limit your learning materials to current generation social media and bite sized treatments. I'm not suggesting to do all the following, but there is gold in there... Old school texts still have a lot going for them, public domain university lectures and problem sets are a world of fun too. Don't be afraid to study codebases you respect in depth. Build, debug, extend etc. I have had hours of fun with postgres and mysql in particular.

This is a great starting point. Being a junior dev is totally fine — Claude will handle most of the hard parts. What you should focus on is broadening your technical breadth, not depth. And the fastest way to expand your knowledge base is to start from a project you actually care about. Nothing beats that.

PostgreSQL is a great database — I use it too, and I'd recommend it.

I wouldn't suggest Java though — it's too resource-heavy. If you have really good server resources, maybe consider it. But I'd recommend Rust instead. Don't be afraid — Claude will write most of the code for you. You just need to know how to debug.

As for Redis, you probably don't need it at the early stage. Only worry about it when your app has a lot of users — by then you'll naturally figure out how to use it.

One more thing: write detailed API documentation first. Everything should revolve around the docs. Don't rush into writing code. Trust me, documentation matters more than code.

Good luck, and go for it!

Java isn't really that resource heavy anymore, especially with the new garbage collectors.

I might be a bit old fashioned, but I do believe that it's necessary to at least understand what Claude is doing for you.

Admitting you can't design architecture shows real integrity that many wouldn't. But honestly, just go for it. Everyone learns from flaws.

PostgreSQL, Spring Boot, Angular, Python, and Redis are all popular choices, so Claude should be well enough versed to teach.

You don't have to go through books and documentation websites, and you'll lose the chance to learn if you try to one-shot it with Claude. It's good to start with a discussion, then build the spec, understand it, and go from there.

I think LLMs are never just vibing tools.

You should go for it, especially because nowadays Claude is a powerful tool available to many. One piece of advise though, everything Claude mentions that you do not understand or not know, make sure you learn it. This is probably the most important part, and applies to everyone using Claude.

Thanks! Great to know

If you want really understand and farm experience, build the app WITH Claude, ask for raccomandation and especially explaination, justifications, do brainstorming, ask to Claude to explain the first principle of the concept he cite, not necessarily relating them to your app

Yes you can and go for it!

Even if you use Claude, as long as you know what you don't know, you can ask Claude to point you in the right direction.

You don't need a senior developer or permission to build.

I cannot answer your main question, but i can give you recommendations wrt what you are gonna try to do.

Very likely there will be a lot of parts of the app you are not going to understand, those will be the main problems so help claude help itself.

Make it add diagnostic/event-logs to every part of the stack and potentially even design implementations around traceability (eg avoid batch background processes that touch many flows if possible). so that claude can check whether runtime behaviour matches expectations. also store historical data to help debug regressions.

Treat implementations as cattle not pets, once a feature is done consider scapping it and turning it into a design doc, then ask claude to reimplement interactively with you step by step explaining to you what is going to do, why it matters, etc. this is a very good way to minimize the black boxes you don't understand in the app.

if the app is web make it work very well with playwright for e2e ux tests.

finally i like the architecture given in https://www.youtube.com/watch?v=4KvbVq3Eg5w (use ui composition to define feature) but this has little to do with claude

Either way, you'll learn something along the way.