I find that playing the game requires a healthy balance between #AutomateAllTheThings and "Don't waste time building a huge factory for something you need very little of OR you don't know how much of it you will need". This same experience/way-of-thinking applies heavily to development/programming in the form of "Premature Optimization". In my first Factorio game I spent WAY too much time building massive factories to pump up every single item I needed. This lead to a boring grind and wasn't efficient at all. I was overwhelmed with making sure I always had a chest full of X item ready for me that I wasted a bunch of time (which, to be fair, in Factorio I didn't exactly waste the time as I had fun).
For me this resonates heavily with as it lead to a sort of "analysis paralysis" that I immediately recognized from my attempts at a side business. The next thing I attempt I am going to make a conscious effort to focus on a MVP above all else and ignore scale completely. My last attempts at building a side business have spiraled out of control quickly as I attempt to right all the wrongs, foresee all the potential issues, side steps all the mistakes I saw happen at work, etc.
In some ways I really miss my days in high school when I would open up a blank php file and start coding instead of wasting HOURS looking into various tech stacks/frameworks/libraries/etc in an attempt to "future proof" my setup. I realize now it's a fool's errand. That's not to say you should never think about how you would scale but at the same time don't let the idea of future success keep you from creating the exact things you are trying to future proof.
In some ways I really miss my days in high school when I would open up a blank php file and start coding instead of wasting HOURS
* I think I'll create a little website for XYZ
* Better setup a GitHub repo for this
* Hmm, I really like using Angular/Typescript since I use that so I'll use that
* Better make sure Webpack is all setup and working
* Should I do my development in Docker since that's how I'll deploy it?
* Maybe I'll try this new NodeJS backend framework that looks interesting
* I need to make sure all my config lives outside of my app so that I don't hardcode values
* Oh crap, I want to share code between server and client but they both have their own Webpack configs and merging the two without screwing something up doesn't sound fun
* What, was was I going to create a website for again?
My most enjoyable non-work programming over the last year or so has been in my ~/git/temp-scripts folder where I can just create a new folder for something, run npm init, and be coding in less than a minute. This is mainly used for, as the name suggests, temporarily scripts or better yet, scripts that I'm not sure if they will have legs or if I'll just use it once. It's pretty much my little playground where I don't have to worry about scaling, reusability, etc.
I get the sense that there’s a gem in your scripting, and one of those might become useful and need more work, and then you’d have a reason to scale it.
There’s [a recent interview with PG](https://www.startupschool.org/videos/36) where he talks about the joys of hacking, you might find it interesting.
I've found, getting back into it, that Project Euler really helps me 'just start coding'. Last time I got into it (around 2014) I would focus on trying to understand the mathematics and solving things by hand. Now I look at a problem or two every few days, and have fairly streamlined solving them.
Breaking the problem into chunks, making sure those chunks work with tests, gluing the chunks together to get the fact needed by the question, running with the specific input needed for the answer, realising the naive way I implemented the solution is way too slow, adding timing information, analysing the algorithmic complexity, reading pages and pages of mathematical theory...
Sometimes it goes off the deep end, but getting some result almost immediately is so useful.
It's the reason Factorio is fun (you can just build it by hand, most of the time) and Excel is used everywhere (you can see the algorithm and its results together, as you build it). It takes a bit of discipline to do yourself, when the gratification loop isn't built in to the tools you're using, and that's why I think Project Euler is so useful. You get short, achievable programming problems that you can solve quickly and build a habit of solving efficiently.
If I signup as a developer, how easy/hard would it be to find a gig? I assume the supply of good developers is not an issue so finding work would be hard.
Yes, we applied to YC. We didn't get an interview. I assume that the market size isn't big enough for VC.
> If I signup as a developer, how easy/hard would it be to find a gig?
Contracting kind of depends on how much energy you put in. We've seen smart people not try that hard, and get zero gigs after 20 applications. On the opposite end, professional contractors who give thoughtful applications get many jobs at high hourly rates.
Moonlight can only net increase your job flow. If you are in need of contract work, you can always email us (team at moonlightwork.com) and we'll manually coach you on improving applications, and make warm intros to clients. (We have had success doing this manually over the past month, and are contemplating on turning it into an automated "I'm available right now" flow in the product.)
Worse ideas with smaller markets have been funded by YC. I'm guessing you could have gotten in if you pitched a larger vision.
It's been a long journey to understand what customers want. I think that a subscription product is our future, and we didn't figure that out until last week! But, we even tested that manually - and, in doing so, have done more net revenue in the previous seven days than we did in the first year of our business.
We've fortunately been ramen profitable this year, but I hope that in 2019 we can start to focus on growth!
A marathon is a race ;-)
Is your idea different?
(Paid is a YC company, btw!)
EDIT: My apologies for the misunderstanding! I didn't realize that you've already built that functionality from your top comment.
One of our technical needs was auto-charging clients for overdue invoices that were neither approved nor disputed. That's application logic, not something we can use an external system for.
Here was our basic workflow:
1. Marketing site set up using Squarespace
2. Developers apply using Typeform. We add them to a Google Sheet with Zapier.
3. New jobs submitted through Typeform, which triggers an email to us
4. We manually set up a new Google Form to collect proposals. We send the results google sheet to the client.
5. We manually search for developers that match the skills of the project and email them all manually to ask them to submit a proposal using the Google Form.
6. Project owner selects a developers. We docusign a contract to both parties.
7. We send a google sheet to the developer to log hours
8. Every week we go through the developer timesheet and manually issue an invoice using PaidLabs.com (with Stripe at backend)
9. When the payment gets deposited, we pay the developer (wire transfer outside USA, Payable.com inside the USA)
We slowly automated each step with a web app, which was published part-by-part as we finished automating a particular step. We did about $100K GMV with this no-code stack before we completed the end-to-end web application.
Today, Moonlight is profitable and bootstrapped. We still manually prototype things. For example, we came up with the idea of a subscription product on Tuesday last week. We had a client agree to it, so we issued an invoice through Stripe Invoices on Friday, collected the money, and are now starting to build subscriptions into the app.