Interestingly, I think we're seeing less people grow up with general purpose computers, and instead just have an iPad or an android tablet, or a chromebook.
Not the OP, but the people I've seen this do it DIY have all done it with Ubiquiti products. A single link can get a mile of range with clear LoS. Depending on how far out you are, that lets you connect to a "real" internet connection for cheap.
One thing you may encounter is that a large company may be using it for many things internally, and that still shows up as just a handful of clones, because they have some central artifact caching service in place.
Essentially this is a way to lets you push all of the weird feature requests your customers might have off into one place.
From a customer point of view, maybe you need to rewrite the path based on the contents of a cookie, or maybe you want to shed certain types of requests in high load scenarios, or maybe there's a buggy upstream application that sends bad cache-control headers, or ...
If the goal is to let the customer specify infinitely complex logic at the edge, a programming language is a good way to do that. Function As A Service is a good billing model for lots of invocations of short, small functions across the customers choice of language.
Why not start out by using the Django Admin features?
That allows you to start with next to no code, but you can easily add a little business logic anywhere you need it eventually, and it provides a way to long term transition to a true application if the need arises.
Facebook will be pitching to your Marketing folks that's exactly where you need it.
Facebook want data on what actions users took before signing up, which users actually signed up and started paying, and how that relates to revenue. This UI is exactly where they can determine these types of actions.
Whether this actually makes Facebook better at marketing or not is a good question.
At my job, we evaluated moving from AWS hosted ES to several of the Elastic offerings. Many of them were more expensive than AWS was before taking hardware into account (as in comparing cost of Elastic licensing vs the whole cost from AWS). This made it exceedingly difficult to justify the move. It's not only the headstart with the client (billing relationship in place), but the cost that hampers them.
If dollars have no value, you should be willing to give away any dollars you have to anyone, no matter how they are using them, right?
Dollars don't have a direct value in gold, but there are people willing to take your dollars and exchange them for gold, it's just a ratio that varies over time, along with the value of gold and dollars.
I (sort of) work in the advertising industry. I'm really excited to see this change, but the major players in the industry just weren't ready for it, and it would have been very chaotic with lots of money on the line.
I think waiting until early 2021 is better than having anything that depends on ad revenue see a huge dropoff until the industry figures things out.
If the problem is that there aren't enough acceptable quality housing with good public transit access, it seems like building more transportation and housing would be a good solution rather than building similarly expensive suburban sprawl.
What I would do in your situation is try to measure the incremental value of future messages, the likelihood that a given message causes an unsubscribe, and the value of the current message to come up with a good balance.
For a small list like this, it may mean separating users into two segments:
* Actively engaged, send them a weekly update
* Not engaged, only send them big new announcements.
Marketers tend to look at link clicks, email opens (measured via embedded images), and engagement with the actual product (if you have it) for segmentation like this.
A good manager should be doing a lot more than just asking you for status updates in your 1:1s. At a minimum they should be:
1) Providing updates on things going on with the rest of the organization that may affect you. Technically this doesn't have be in a 1:1, but is often a good venue.
2) Learning more about any problems facing the team, and discussing potential solutions.
3) Giving feedback on both what the employee has been doing well and any areas they could improve.
4) Helping to set goals that will advance the employees career goals.
While you might be able to get everything done well with lots of autonomy, you're probably still leaving value on the table by not meeting more regularly.
I did an online food ordering startup a ways back, and it was very surprising how few of the restaurant owners we talked to had clearly thought through pricing strategy for things like this.
We had originally gone in with clever ways for owners to describe how different changes would affect the price of an item, but ended up landing on just a giant matrix where they could input the end result price for any combination. The owners couldn't articulate their own pricing well enough to model it well.
In a series of calls with the top tier of support at Paypal, no one was able to even answer which API was the best to use. I was told not to use SOAP (or NVP), because they're ancient, not to use REST because it wasn't ready yet, and that the Braintree API around PayPal would never support the features we were trying to implement.