Weekly Update #20: Software Contracting Isn't Bad

This is a summary of my sabbatical's development for the week of June 20th, 2020 to June 27th, 2020.

Goals from last week

  • [❓] See what I can ship for FormDeploy, optimizing for minimizing time-to-ship instead of maxmizing new learnings.

What I got done this week

  • [❌] See what I can ship for FormDeploy, optimizing for minimizing time-to-ship instead of maxmizing new learnings.

Didn't really manage to ship anything for FormDeploy. I took on some work for a client on a contracting basis. I just finished phase 1 deliverables with a possible additional phase 2 of development work pending the client's response, and I'm cautiously optimistic that this may grow into a viable BATNA and a form of both income and capital growth.

The one problem I had this week is, I severely underestimated the amount of time it would take in order to get up to speed on this matter. I thought this development phase would be 20 hours. I ended up putting in closer to 80 hours, or a 4x multiple, which means I ended up charging 4x less than what I had originally planned.

How do I feel about that? I'm honestly not angry at all. I'm really excited that this is the first week I've been really productive. Working for money as an incentive is really nice especially if your food security is really low. And I really like the freedom of contracting. I check in with the client twice daily, once in the morning or afternoon, and once in the evening, and they just say “thanks for the update”, as opposed to working a salaried job where my leash is much tighter. At the same time though, this past week does showcase just how much more investment I need to make into my personal infrastructure in order to create viaable SaaS MVPs in days instead of a week. This is also good knowledge to have for FormDeploy, and TinyDev, because I'm likely far more behind for those (much more technically advanced) projects than I had originally projected.


  • Weeks to launch (primary KPI): ? (1 week after product development begins)
  • Users talked to total: 0

RescueTime statistics

  • 80h 25m (73% productive, 35% increase from previous week)
    • 46h 20m “software development”
    • 16h 33m “utilities”
    • 5h 31m “communication & scheduling”
    • 5h 14m “news & opinion”
    • 4h 26m “uncategorized”

iPhone screen time (assumed all unproductive)

  • Total: 27h 13m
  • Average: 3h 53m
  • Performance: 7% increase from previous week

Hourly journal


Goals for next week

  • [❓] Wrap up phase 1 deliverables for client, and begin phase 2.
  • [❓] Productionize the HTML editor, ship it as a standalone React.js app, and reference it (using <iframe>) in a Bytes by Ying blog post.
  • [❓] Template out infrastructure for generalized SaaS-based products; generalized SaaS landing page, generalized frontend (with React.js and Tabler) for app frontends, Django + gunicorn + PostgreSQL for app backends, and AWS + Docker for infrastructure.
  • [:question_mark;] See what I can get done for FormDeploy (spreadsheet-based Zapier).
  • [❓] See what I can get done for TinyDev (tiny version of Firebase, with HTTP/2 SSE as the realtime layer).

Things I've learned this week

  • WORKDIR screwed me over big time. Originally in this blog post, I mentioned how this snippet of code:

    # Setup workdirectory.
    RUN mkdir /app
    WORKDIR /app

    As a summary of that blog post, using WORKDIR is really nice because your local development environment is now fully Dockerized, which means you can version system-level and multi-language / multi-framework changes very easily.

    Then you want to deploy to production. Every time I deployed to Heroku, or AWS Elastic Beanstalk, it would always say something like “the app is not found”. I had no idea what was going on. Finally, I deployed to AWS ECS with a EC2 type, meaning I can SSH into the EC2 instance and then docker exec -it ${CONTAINER} bash, and found that the files simply aren't there. I guess I could have run heroku run bash and found the same thing, but I didn't know whether that was because of Heroku or something I did. I think this cost me about a day or so, because everything worked in my development environment perfectly.

    My misunderstanding was thinking docker build $(pwd) would copy everything from my local directory to my Dockerfile. I forgot I didn't do that with WORKDIR, instead I had mounted my development directory as a Docker volume. I'm pretty glad I segmented out the development and production aspects of Dockerization, because that meant I can run COPY instead of WORKDIR in my production Docker environment in order to confirm that the hermetic Docker container contains everything it needs to run properly.

  • I experienced my first live production server “attack” this week! I wanted to get ECS up and running for the customer, and in order to facilitate easier connection to the frontend, I attached a DNS alias to the load balancer address to my personal DNS nameserver (which from my blog posts are heavily indexed). the moment I connected DNS, I got flooded with alien requests. Here's the complete CloudWatch logs for the event. I'm using PostgreSQL and Django, so there's no PHP or MySQL involved in my stack at all. Immediately after getting that flood of requests, my ECS instance went down, and I decided to take it off DNS because screw that noise.

    I had thought it was a DDoS attack at first, but as it turns out, this isn't uncommon. Kind of crazy how much work goes on behind the scenes for a service like Elastic Beanstalk or Heroku in order to not have that happen. If I'm going to be contracting, I want to have a value-add proposition that gives customers optionality between clouds (in order to save money over time), and that means learning to configure stacks from the VPC layer on down. Which means I'll need to learn how to configure security groups and firewalls myself. Fortunately, it should be fairly easy to template using CloudFormation or Terraform.

    This was all very interesting. I'm so grateful I purchased AWS developer support, and that I have somebody to talk to about this matter.

Subscribe to my mailing list