Project: Message Everywhere

This is a companion discussion topic for the original entry at

Posting these exchanges here with Jeff’s permission because it helps to “open kimono” show some of the current thinking with the Message Everywhere project around platform selection and the tradeoffs/priorities being considered:

[Sean Tierney ]
Had one other thought here (lateral thinking): Is the main motive behind porting to FlutterFlow the cost? If so, just wondering if I could negotiate something with Bubble to get a special deal due to the nature of the project and bring the cost down to commensurate with what it would be to host via FlutterFlow then we wouldn’t have to port it and could just finish the broadcast msg capability with what Tonya built… granted it would still suffer the vendor lock-in aspect but assuming we’re ok to put up with that, it would be the fastest path forward. I just didn’t remember if there were other fundamental issues motivating the port to FF…

[Jeff Boles ]
Hi Sean, isn’t a real issue with our cost, but the licensing structure and cost model make it not a competitive community project, and kill the PA aspects IMO. Single individual account in the bubble ecosystem at low message volumes make it already cost prohibitive at grass roots activity levels, and create a non-viable non-profit administrative burden (one individual account structure at starter licensing). The whole bubble deal is just bad in terms of distributable projects I think. We’re trying to reduce to messaging costs only, with a largely free to use app layer. Add in Bubble, and orgs are better off just using off the shelf solutions at $0.05 to $0.10 a message style costs. Us too perhaps. We have a functioning Twilio/AWS/PHP stack. If we’re not interested in serving the community then I just need to source a good Lambda/php developer and spin up a UI for branching survey management on top of what we have. It’s probably a coin toss of whether we move it to Bubble for a better unified single interface. But it’s definitely not a community solution in my opinion.

[Jeff Boles ]
And I’ll also point out that we’re just hanging out in our existing low code paradigm, which doesn’t need to be definitional, but since we’re here, it seems like the FF community is worth poking around in until we’re convinced its a dead end (or preferably not!). Like I mentioned before, it doesn’t need to be low code or flutterflow, it just needs to be well packaged, maintainable, and easily configurable/deployable. But we meandered down this bubble path, and now we have something that looks FF ish, and like FF would tackle the main issue with Bubble (perpetual per org and functionally constrained licensing), so maybe it’s worth the extra stab at the FF community to see if there’s anything there. Bigger picture, it also seems like FF from my limited knowledge better fits the community project paradigm, and could be a better enabler if a few resources were PA connected. If people exist :wink:

[Sean Tierney]
Yup. Ok understood on all counts. I saw your response to Miguel. Does it make sense to embrace the open source aspect here and put our exchange in the Discourse thread for the project so people can see the thought process and participate / make recs / intros / help steer platform choice? I know the platform choice is a bit of a “who do we have involved” thing at present but as that firms up then our dev pool becomes clearer and targeting help should in theory get easier.

And this with a potential Flutter dev who may be participant at our event this Saturday:

Jeff Boles|4:37 PM (2 hours ago)
Hi Miguel,

Great to meet you. Yes, I can make myself fairly flexible tomorrow within the constraints of Arizona time if you’d like to chat.

I hope Sean sold you on the community aspects for this project and the power of a hackathon meetup to some degree. What we’re pursuing is taking place within the community impact paradigm of Problem Attic, and not just a one off consulting project even though we have funding and the proceeds and financial outcome may be the same. With that focus in mind, we’d be chasing a readily deployable, licensing free, SMS and chat messaging solution that targets communities who are “digitally divided” and largely restricted to low connectivity devices, and spans 1) interactive use, 2) structured/automated use (broadcast, chatbots), and 3) structured flow us (survey data collection).

We currently have a more complex infrastructure doing all of this, but needing more survey flexiblity, and it uses Twilio and various functions and flows integrated with Lambda/PHP/Dynamo, and 3CX VoIP PBX message queues as a front end, which isn’t sufficiently deployable for most grassroots orgs. Platform doesn’t matter much, but as it has UI needs and needs to be readily deployable and configurable (and perhaps extensible to other integrations) by low technology grassroots organizations, we initially did a low code pilot of interactive messaging in Bubble, which was interesting. As a significant portion of the use case for these types of tools is enhanced and streamlined data collection for community services, as well as research, low code platform connections to offer some value to grassroots organizations for easy upskilling and integration with other systems, but this doesn’t need to be architecturally restraining.

So much flexibility here for product selection and architecture, but a big element is to carry this out as a community project, for community impact, with a target of broadspread use by grassroots orgs to tackle digital divide issues. I’m not in Lisboa Sean’s platform is rapidly building a uniquely agile community of innovators, and his meetups are a great deal of fun and great connectors. We’d be looking for participation in the ProblemAttic community, and ideation and documentation through Discord channels, etc. ProblemAttic is ultimately where payment would take place.

If this sounds interesting to you, we’d love to chat further, and hopefully get you connected to ProblemAttic’s hackathon.