2 ms·

I announced two weeks ago that we are shutting down Staffjoy [1] and open sourcing our code. Last week, our primary V1 repo was submitted to HN [2]. Yesterday,

I announced two weeks ago that we are shutting down Staffjoy [1] and open sourcing our code. Last week, our primary V1 repo was submitted to HN [2]. Yesterday, I open-sourced our V1 microservice Chomp for computing shift scaffolds from forecasts [3]. I also also published our YC Fellowship application [4] and pitch decks [5] on our blog. Today we opened the V2 repo of Staffjoy, which contains a microservice architecture, detailed here [6]. V2 was a monorepo, meaning that all of the code is in one repo. This is the largest and most sophisticated of our repositories. You can learn about the difference between V1 (autoscheduling of hundreds of workers) and V2 (Excel replacement with text messages for small businesses) in our design journey blog post [7]. We are continuing to open source our last repos, which are mainly V1 microservices. Specifically the V1 Cron microservice, V1 mobile applications (iPhone + Android in React Native), V1 Scheduler microservice (our first scheduling algorithm), and the V1 Mobius microservice (which solves an assignment problem) will be open-sourced in the coming days. If you have any questions - please let me know! I'm providing contract support for anybody wishing to deploy, modify, or customize Staffjoy code through Moonlight [8]. [1] Shutdown announcement: https://news.ycombinator.com/item?id=13647382 https://news.ycombinator.com/item?id=13647382 [2] V1 "Suite" https://news.ycombinator.com/item?id=13730488 https://news.ycombinator.com/item?id=13730488 [3] Chomp service https://github.com/staffjoy/chomp-decomposition https://github.com/staffjoy/chomp-decomposition [4] YCF Application: https://blog.staffjoy.com/staffjoys-yc-fellowship-application-5771c8a105cd#.lvnoezlpr https://blog.staffjoy.com/staffjoys-yc-fellowship-applicatio... [5] Pitch decks: https://blog.staffjoy.com/staffjoys-pitch-decks-that-raised-1-7m-15812018968#.5k08omn51 https://blog.staffjoy.com/staffjoys-pitch-decks-that-raised-... [6] V2 Architecture: https://blog.staffjoy.com/staffjoys-v2-architecture-9d2fcb4015fd https://blog.staffjoy.com/staffjoys-v2-architecture-9d2fcb40... [7] V1 to V2 Design Journey: https://blog.staffjoy.com/staffjoy-v2-ca15ff1a1169#.ttejeklwn https://blog.staffjoy.com/staffjoy-v2-ca15ff1a1169#.ttejeklw... [8] Contract support - https://www.moonlightwork.com/staffjoy https://www.moonlightwork.com/staffjoy

hoodoof 10y ago
In hindsight, what would you have done differently with the architecture of this software? It's got alot of moving parts - do you think it is overengineered?
- philip1209 10y ago
  It's overengineered for today. The datastore should have been a monolith. However, splitting up accounts and companies made us think in terms of microservices. We were prepared to add a bunch of other messaging services on the backend behind bot, so I think that architecture was forward looking. Faraday was my favorite piece of software there.
tarr11 10y ago
That's a really pitch great deck, Philip. Thanks for sharing. I have to admit - I don't totally understand why you pivoted for your V2. Couldn't you have just added on the "SMS" feature to your existing product?
- philip1209 10y ago
  We had some failed deploys due to usability issues. We also felt like we were starting to converge to the same set of features similar to a bunch of other companies (Homebase, WhenIWork, Humanity/Shiftplanning, Deputy, etc). We decided that we needed to do a lot more user research in order to understand customer needs, and others' products. (We also started to realize that, to do algorithmic scheduling, we would need a portfolio of algorithms - not a generic one - which was a tough job for a two-engineer team). Partly, we decided to try to just focus on a great scheduling experience rather than build lots of features quickly. So, the SMS came out of the user research and a need in the market. Our strategy was going to be integrations. We had a slew of API integrations lined up for POS, payroll, and other providers.
tedmiston 10y ago
Thanks for open sourcing this. Just a heads up — your phone numbers are in the sms service.
- philip1209 10y ago
  Ugh, I don't think it's worth force pushing to erase. I pushed a commit to remove them, though. Thanks.
bsbechtel 10y ago
Phillip, I'm sure going through all this as a part of your shutdown isn't easy, but it's really great that you're taking the time to do it. I'm sure there are many who will benefit from making all of this open source. Many thanks and best of luck going forward!
- philip1209 10y ago
  Thanks! Please reach out if I can be a resource too.
tixocloud 10y ago
Thank you so much for sharing all that you've learned throughout your journey and for sharing your architecture. Curious but with a working web app, what was the motivation for building an external REST API?

hoodoof 10y ago

In hindsight, what would you have done differently with the architecture of this software? It's got alot of moving parts - do you think it is overengineered?

philip1209 10y ago
It's overengineered for today. The datastore should have been a monolith. However, splitting up accounts and companies made us think in terms of microservices. We were prepared to add a bunch of other messaging services on the backend behind bot, so I think that architecture was forward looking. Faraday was my favorite piece of software there.

tarr11 10y ago

That's a really pitch great deck, Philip. Thanks for sharing. I have to admit - I don't totally understand why you pivoted for your V2. Couldn't you have just added on the "SMS" feature to your existing product?

philip1209 10y ago
We had some failed deploys due to usability issues. We also felt like we were starting to converge to the same set of features similar to a bunch of other companies (Homebase, WhenIWork, Humanity/Shiftplanning, Deputy, etc). We decided that we needed to do a lot more user research in order to understand customer needs, and others' products. (We also started to realize that, to do algorithmic scheduling, we would need a portfolio of algorithms - not a generic one - which was a tough job for a two-engineer team). Partly, we decided to try to just focus on a great scheduling experience rather than build lots of features quickly. So, the SMS came out of the user research and a need in the market. Our strategy was going to be integrations. We had a slew of API integrations lined up for POS, payroll, and other providers.

tedmiston 10y ago

Thanks for open sourcing this. Just a heads up — your phone numbers are in the sms service.

philip1209 10y ago
Ugh, I don't think it's worth force pushing to erase. I pushed a commit to remove them, though. Thanks.

bsbechtel 10y ago

Phillip, I'm sure going through all this as a part of your shutdown isn't easy, but it's really great that you're taking the time to do it. I'm sure there are many who will benefit from making all of this open source. Many thanks and best of luck going forward!

philip1209 10y ago
Thanks! Please reach out if I can be a resource too.

tixocloud 10y ago

Thank you so much for sharing all that you've learned throughout your journey and for sharing your architecture. Curious but with a working web app, what was the motivation for building an external REST API?