Reality check for self-study + project schedule?

[wakyct]

Hi, I don’t program professionally and I’m considering taking time off work to write a web app in Clojure/Clojurescript. However, just like I could look at a project in my line of work and estimate whether the timeline makes sense, I would appreciate advice from the professionals here whether my imagined schedule is unrealistic or not.

The web app would be similar to this tool, a construction jobsite management app. Its main functions would be:

• file upload/viewing
• task list management
• form creation/management
• photos in-app associated with tasks/forms

I would like to write this app in six months, spending approximately 25 hours a week (so about 600 hours).

The kicker is I also would need to learn enough Clojure/Clojurescript, and devops, to make this happen. I do know how to program, but just at a hobby level – equivalent to 1 year of experience maybe?

Thanks very much in advance for any help!

[mvarela]

Without trying to be a wet blanket, your schedule seems a bit optimistic, but then again, the description of what you want to achieve is too vague. Do you intend for this to be production-ready, and similar in features to what you have linked to? If so, given that you have little experience programming and are just starting with Clojure, I think you’re probably trying to bite more than you can chew.
If it’s meant to be a bare-bones MVP, with a very well-delimited set of features (easier said than done, but feasible), then it might be doable, to some degree.
Remember Hofstadter’s Law!

In any case, I think you’ll find you can get a lot of help from the community here…

[thheller]

I’ll answer that question by asking another question: How much time do you plan to maintain and extend it after the initial implementation?

Software is never really done and needs to be maintained/fixed/extended. If your plan is to write this and never touch it again, then don’t start. If your plan is to start and grow after, then it could be doable but it’ll be tough. None of the listed tasks are trivial and can become insanely complex depending on requirements. So, even finishing one of those could be tough in 6 months.

[zcaudate]

My advice would be to take a slice of the functionality and try to do that first → say the file upload/viewing and timing your progress.

You’ll get a good idea of how much time you’ll be taking and then you can do further estimates based on that. Although… the more features you build, the more time you’ll spend juggling those features around so factor in that as well.

Making the site look good and the interface feel snappy also takes a lot of work so 600hrs is probably not that much time - but good on you for having that goal. I’d say go for it.

---

having said that… fullstack is hard, so even with the file viewer part, there’s a crazy amount of things to think about:

• where are you going to be storing the files? (custom/aws/minio/messing with http protocols)
• who is going to upload/who will have access? (db/permissions)
• what file formats are supported/viewable? (ui stuff)
• are you going to write everything yourself or pick off the shelf components? (this can potentially take alot of trial and error to get right).
• why not use typescript/nextjs? (it’s easier to get more devs onboard).

So that alone could be 600 or even 1600hrs of potentially a lot of experimenting, learning and integration. Again… it really depends on what’s motivating you.

[wakyct]

Thanks everyone, this is exactly the kind of feedback I was looking for.

[didibus]

To the level of quality that the linked website you provided appears to have, I’d say you’re looking at a year of work for a team of 6 composed of 2 juniors, 2 mid-level, 1 senior and one team lead + a PM and a UX designer.

But you can probably hack out a POC, maybe even something that gets you a first customer, where you’d give yourself 6 months for each of those features. Going that route, you’ll probably grow until your POC reached it’s tipping point, and then would need to hire that above team I mentioned to take a year to either rewrite or majorly refactor your POC so it can handle the next hundred customers and also keep your existing ones happy.

Similar to some other’s advice, I would try something called a spike. Basically, don’t quit your job just yet, but maybe try to take a 4 week leave. Then try to get the most minimal barebones version of one of your features going.

From that, you’ll have learned the complexity you’re looking at, the challenges, the difficulty, and your own velocity (how fast you make progress).

You can then decide if you should quit your job or not.

Addendum: Also, when you do that, when I say minimal, don’t take shortcut, you want to go fast (not worry too much about doing everything right and perfect, have the mindset you’ll probably throw it away and start over anyways), but make sure it is usable as a user in the way you plan to sell it. So like it should immediately handle someone signing up, logging in, and all that. It should be immediately deployed to a host or cloud, not just running locally. You want to make sure you’ve learned about the end-to-end challenges. What you can go fast on is code quality, test coverage, the UI/UX can be crappy and barebones, and only have a single basic feature. But try to make it like, even if that’s all it is, you could already have users signing up and using it in production.

If you don’t do that, you’ll get a very skewed impression of the real work involved.

[bpringe]

To maybe reinforce what others have said here, you should do a complete vertical slice of one small part of the planned system. That means design, coding, and deployment - get a fully working system out that just does one simple thing, but that is hosted as it would be in the end. That might look like just having the signup/signin feature implemented in a sense that it just works and then there’s nothing after signing in, but you now have a hosted system and a complete vertical slice.

Just keep in mind with this initial slice not to spend time making it look pretty or making the code factored well or even having much test coverage, if any.

After you do this, you’ll have a better idea of the challenges of each part of developing other features, from design to deployment. You also might realize something you want to change, such as the format you store data in, or the storage system you use, based on what you learn about hosting/deployment or maybe off-the-shelf tools you want to use, and it might be easier to make the change only having done on simple feature than it would be if you’d had that realization after doing way more coding.