Nice effort to open source your code - kudos to you.

I remember checking out Staffjoy last year sometime, out of curiosity. Seemed to be a nicely designed system that fitted a niche.

I too wonder why it never took off - having consulted in the small business area for 3 decades now, rostering and checking staff availability is a major pain point for business owners, especially those running cafes or security services, catering etc.

Heck, even my wife is on an automated rostering SMS system for her part time job, and it works well and seems to alleviate a lot of stress for her boss. I am surprised that $9/mth wasn't an automatic "Shut up and take my money" for a lot of businesses. I know there is a lot of competition, but surely there is plenty of pie for a few players to be in the same market.

I hope to perhaps one day hear a more detailed post mortem about the business, rather than technical, challenges faced by the founders of Staffjoy.

> I am surprised that $9/mth wasn't an automatic "Shut up and take my money" for a lot of businesses.

Maybe because the presentation on the website was unclear. It showed neither UI, now workflows nor anything. I did not even know from a quick glance that this sends text messages.

i agree re workflow

however, on the mobile site right in the middle of the screen it says "Create a schedule online. We notify your team using text messages." which seems pretty clear

"I hope to perhaps one day hear a more detailed post mortem about the business" -> https://blog.staffjoy.com/staffjoy-is-shutting-down-39f7b5d6...

Author here. Just noticed that this was submitted. I'm fixing some CI stuff now, and finishing the open sourcing of some other services like Cron, Chomp, and Mobius. This the V1 of our product, intended for larger companies like call centers. I'll open our V2 product for small businesses asap.

Cool release! Thank you for this. It's always great to see production code get released as opposed to pet projects.

What's interesting to me is that even though it's a flask app, it seems to be re-implementing large chunks of Django:

- Similar directory hierarchy including folder-per-app, templates, config

- A big settings object that gets passed around to things like Celery

- SQLAlchemy for the ORM/database glue, some other components for migration management

- Re-implemented authentication that has a very similar feature set to django.contrib.auth

This convergence reinforces that I should keep using Django or Rails for new web/mobile products. I find myself doing all of the above when using Go or Haskell for the same task.

I'm a big believer in using an "everything but the kitchen sink" kind of framework like Django or Rails for MVP or very early versions of a web product.

The fact that they're typically opinionated about how basic things should be set up can save you from wasting time/analysis paralysis on inconsequential decisions and help get a prototype running, at which point you can decide whether it's a good fit or if you want to factor parts onto another platform.

I find that Django composes a lot more nicely than Rails, and of course that's not necessarily good nor bad; really depends on the use case. To me, Django feels like a Ford F-150 where everything is more or less exposed and easy to hack on. Rails is more like a tight well-oiled VW that runs very smoothly but may make you bend over backwards a bit to use an aftermarket part.

My pipedream is a framework as comprehensive and mature as either of these two, but in a language with a good static type system to save on 50-80% of tests, and enjoyment of many other benefits.

Keep in mind that this is the version 1 so might straddle the line between pet project and production.

IIRC, they built a version 2 due to various issues.

But, yeah, version 1 should definitely be built using tech that comes easiest to you.

Version 1 was our primary product for 16 months. It still has customers using it at suite.staffjoy.com. We are helping some of those customers run the software on prem during the shutdown.

Wasn't trying to cast aspersions/take anything away: I think it's great that you are open sourcing anything. Kudos.

I was just pointing out that this infrastructure might have been great to start, but you guys moved to a very different, in terms of architecture , v2.

I've never used Django. I based the original flask app on Michael Hartyl's book.

That's cool it's being opened sourced versus simply dying. Though it's odd that, even though the repo says they're shutting down, their website shows zero sign of that at all and is still encouraging users to sign up.

Also, was this the Homejoy v2 attempt? Seems like contractor scheduling services don't provide enough value to the contractors and customers to keep them from dealing without them once the contact is made. Curious if there are any successful companies that provide the same services, with actual revenue, and what they did differently. It's gotta be something to make the customer and contractor stick to the platform.

Clicking the "Sign Up" button on the home page goes to the blog post explaining that they've shut down.

HomeJoy and StaffJoy are made by different people, afaik.

You are right.

Any screenshots of what this looks like running?

Some V1 vs V2 screenshots here: https://blog.staffjoy.com/staffjoy-v2-ca15ff1a1169

Thanks!

9$ seems really so low, I cant imagine charging less than hundreds of dollars for this.

There are a bunch of competitors and SMBs very much care about the price tag so 100s of dollars is a massive stretch[0].

Note that this alleviates the pain of the staff, not the business ie vitamin for the entity paying for it, but pain killer for their part-time workers.

But, I do agree pricing is out of whack. I would probably try to charge directly based on the number of staff managed (eg: $1/staff member/month).

[0] I run a startup selling to SMBs in the service sector. Upfront dollar amount is a massive hurdle. However, upsells/elastic pricing based on users is easier.

> Note that this alleviates the pain of the staff, not the business

It is a pain for the business when the right people don't show up at the right time, though.

Problem is those staff are seen as fungible and the onus is on them to show up. Didn't show up enough times? Well, you are fired. That's a pain point.

A colleague didn't show up: well crap now you have to be a team player and cover for them. That's a pain point.

A staff member didn't show up? That's an annoyance.

Cool. Just checked API documentation [1], looks great. What tools/language/library are used?

1. https://docs.staffjoy.com/v2/docs

Looking at the requirements.txt in the repository, it's a Python project using Flask, SQLAlchemy and Celery with MySQL and Redis for storage.

I meant API documentation. Looks like they've Apiary-like interactive documentation.

Oh. Seems to be something called readme.io? http://readme.io/

Yep. But I was looking for some open-source solution other than Swagger.

You can get a layout with similar functionality using Slate (https://github.com/lord/slate).

Why has the Git history been squashed for security? What in the history of this repo is sensitive? Were there passwords or credentials?

I imagine its more of a precaution, I know I've worked on closed commercial projects where the commit history is sprinkled with business rationales for changes, and even the occasional grumpy word said about specific clients. Given they're doing this while winding down the company they may just not have time to audit every commit in a large project for sensitive information.

We hard coded some dev API keys, like email. We also had some customer names which we can't disclose committed in the early days of the repo.

Do you have any sample data to stick in a database? That would be amazing, particularly if it's based on (or is) real data.

When it's running, you can set up a "free trial" that does some basic provisioning. The smoke tests also spin up and down orgs, and may be helpful.

Or I wonder if someone could get some sort of demo hosted.

Very cool, followed the instruction and got it working! What's the license ?

I can't seem to be able to log in - seems possibly due to a missing Mandrill API key. Given that Mandrill is apparently now a paid addon to mailchimp, how'd you get around this?

You could PR a generic SMTP configuration if you want. I just haven't had a chance to do this.

The github project has a license file that says MIT

link for a working demo?