LeFever

Sorta!

Stripe recently launched an entitlements API [1] that is meant to aid in provisioning and deprovisioning customers, but product integration is not provided (You create subscribe/unsubscribe webhooks and update the entitlements in your own data model, after which you need to build the APIs and functionality to use them). As you alluded, this is actually complementary to Planship, and integration between Stripe features/entitlements and Planship levers/entitlements is something we're considering pending customer feedback.

Thanks for the question!

[1] https://docs.stripe.com/billing/entitlements

Thanks! Great questions.

1. Today, we coexist with entitlement solutions (feature flags, auth systems, etc) by either working alongside them or feeding into entitlement aggregators. Basically, we handle the pricing-related data, logic, and aggregation that eventually reduces down to flags (Or numeric values, lists of items, or other value types). We offer SDKs to make these pricing entitlements easily accessible within a product marketing page, app, etc., but our API can just as easily be used to integrate with other systems.

2. We store complete subscription renewal history but the API for accessing it isn’t public yet. Audit trails, both for customer behavior like you mentioned, as well as admin tasks (E.g. Entitlement value X was added to plan Y) will be available via our API and in our console.

John Bolton and James Bach are the founders of RST [1] and generally big names in the “formal” software testing space. Presumably the testers.ai folks aren’t fans. :p

[1] https://rapid-software-testing.com/authors/

I’ve been working on a project to make SaaS (and really any software) pricing and packaging easier. Think things like plans, entitlements, dimensions, metering, subscription migrations, onboarding, and experimentation, all completely independent from billing and payment processing solutions. We can integrate with things like Stripe where we’ll mirror products, customers, and subscriptions, but it’s totally optional.

We’re 100% bootstrapped by way of a previous acquisition and just very-soft launched after talking to a lot of folks at companies of all sizes. Seems like most people end up cobbling this stuff together with various levels of sophistication, which is basically what we did a few times over at previous companies with varying levels of success.

You can check out our solution at https://planship.io.

This looks nice! I noticed that you mention logos in the docs but don’t see a way to specify one. Maybe I missed it?

Maybe they’ve been added since you looked, but there are two Beecher’s-related cheeses listed for Seattle [1][2]. You have to click the number next to the Seattle dog to see the complete list of dishes that includes them.

And not to pile on, but the Seattle dog is definitely popular and somewhat ubiquitous to the point it’s common to find cream cheese next to the other condiments at backyard barbecues.

[1] https://www.tasteatlas.com/beechers-flagship

[2] https://www.tasteatlas.com/marco-polo/

Some of these immediately resonate. I'd love (4) to be a reality but it's going to be a struggle to get there, not that it isn't worth striving for. And while I agree with (5), the "covers" are often complex/dynamic and where a lot of difficulty in implementation and maintenance occurs (Sorta touched on in (3)). (6) is what got us thinking about this idea of distilling entitlements in the first place.

Will definitely reach out. Thanks!

This is cool! We're just starting to look into this area as we integrate pricing/billing/plan logic and entitlements at scale. Thanks for the example and reminder to read through the Zanzibar white paper.

ironically with totally non-transparent pricing

Oh man tell me about it. I also think the trend towards metered, pay-as-you-go pricing in general doesn't make sense for many businesses or their customers, but I digress.

Curious if you've thought much on how to distill feature-flag entitlements, service-limit entitlements, role-based entitlements, billing-based entitlements, and so on to a single interface like "Can I [action]?"

Edit: Ha, just saw your reply in a separate thread. Yes, you have thought about it. :) Would be curious to learn more.

I'm actually working on a solution to plan entitlements among other similar functionality right now. While you can get a basic solution set up with feature flags, we've found that the organization and evolution of billing/pricing-related entitlements (E.g. plans, editions, etc.), especially over time, is increasingly complex with lots of requirements in the peripheral. Think things like varying combinations of feature, seats, and usage-based/metered strategies, team subscriptions, plan migrations, one-off enterprise plans, multi-subscription customers (E.g. promotion periods and layered subscriptions), usage aggregation, automated upselling, etc.

As you show in your blog (Nice post btw!), while you can have a flag with a numerical value representing a limit, the infrastructure for tracking usage is left to the business to implement. Imagine instead that you emit usage of that lever to an entitlement service and entitlements based on that usage are updated in real-time, even across teams. Also imagine that you have other entitlements that may be dependent on that entitlement that update as well. In addition, as limits are approached or crossed, you can choose to have soft enforcement (I.e. let them continue, but notify sales to reach out) or hard enforcement and display a prompt to upgrade.

In the spirit of OP's link, we work alongside existing billing solutions rather than try to reinvent the wheel there. We're bootstrapped via a previous successful exit and working with early customers, so if anyone's interested in chatting, even to just geek out on this topic, please reach out: trent at planship.io.

It’s kinda clever. The people most likely to look at this project are also likely ideal candidates for implementing the library in a new language (Developer, FOSS enthusiast, interested in the project, need the library in a language they’re familiar with that isn’t implemented yet).

Also, the language pills differentiate between those that have been implemented (color logo, dark text, bold) and those that aren’t (grayscale).

Definitely agree. Ideally you’d be able to extend the search engine list in Safari’s settings but alas.

I know we’re really getting into the weeds here, but I’m curious what issues you’re having with iOS Safari and Kagi. I’m using it with both normal and private tabs and it’s working great. There were a series of fixes in the past month to the Kagi app (necessary for Safari integration) that specifically addressed issues with private browsing. Might want to try it again. Good luck!

They’re claiming not to have analyzed comms in the US:

"This data comprises the encrypted messages of all of the users of Anoms with a few exceptions (e.g., the messages of approximately 15 Anom users in the U.S. sent to any other Anom device are not reviewed by the FBI)," the document reads.

From From https://www.vice.com/en/article/akgkwj/operation-trojan-shie...

I've had mostly mediocre or downright poor experiences with curbside pickup.

Most recently at Lowe's I called the number on the parking sign and was put on hold, and then it hung up after a few minutes. When I called back it was busy so I moved to a normal spot and donned the mask and went in. Then, when I got to the desk, I had to do the back-and-forth of giving an order number, name, etc, and then wait for them to find the order.

Full disclosure: I co-founded Routegy and happy to answer questions about how we're helping businesses build better contactless experiences, including curbside pickup.

Having never used GitLab, what do you mean by growing from a SaaS perspective?

Except it isn't a fork. It's basically two projects merged into a new one and a small blurb in the readme to that effect. Why not fork and contact John about taking the original one over? If he doesn't respond within a reasonable time, run with the fork. I don't get the sense that happened here.

I think the issue is less about license and more about what is good form and helps to keep the ecosystem a bit less cluttered.

AppThwack (https://appthwack.com)

WHO WE ARE

AppThwack allows developers and QA teams to quickly test their Android and iOS apps on 100s of real devices. It's 100% automated and a clear, helpful report with high-level results, low-level logs, screenshots, and performance data is built in minutes, allowing people to catch issues well before publishing to the market.

AppThwack started in March, 2012, and since that time we've raised a seed round, rapidly grown revenue from customers of all sizes (Intel, New Relic, and Unity to name a few), and recently (yesterday) moved into a new, larger space. We’re located in beautiful downtown Portland, Oregon, and we’re looking for talented and motivated people to help us build the best automation tools in the world.

JOBS

Developer Relations & Community Building - In this role you’ll be responsible for interacting with the development community, managing outreach (blog, social media, etc.), and organizing events. You'll work closely with the team, both development and sales, to build competent, helpful content for our current and future customers. You ideally have experience marketing SaaS products to a highly technical audience in a non-slimy way.

Preferred location is Portland, Oregon, but we can make exceptions for the right person.

For a full list of positions, including internships, see https://appthwack.com/jobs

INTERESTED?

Please contact me directly: trent@appthwack.com

I've talked to hundreds, if not thousands of developers at this point, and I think that although mobile test automation isn't as common as it should be, it's definitely growing in popularity (Think of the rise in popularity around web automation via frameworks like Selenium over the past 10 years). One of the major reasons is competition is ridiculously fierce and customers are very unforgiving, so quality is increasingly important.

Regarding tools, on both of the major platforms there are a number of popular, open source frameworks for writing tests. Robotium, UI Automator, Calabash, UI Automation, KIF, and on and on. Which one is best depends on the people creating the automation and the type of app under test.

Lastly, regarding the education piece, you're absolutely right. Automation is a software engineering project, yet all too often it's not treated like one. You can look for a magical solution (Test recorders, "crawlers," etc), but in the end it takes time to build sustainable tests, and those magical solutions end up being hindrances in the long run.

Disclaimer: I'm a founder at AppThwack...and even though we have a built-in compatibility suite with an automatic app explorer and stress test, I still push everyone I talk to to invest in engineering good, reliable test automation. We come from the enterprise world of test automation and have seen the massive time and money sinks a poor automation strategy creates.

P.S. Congrats Kevin! Best of luck at Appurify!

Thanks! Glad to help. Definitely exciting to see some new competition in this space (or in this case, old competition getting refreshed).

(I'm a founder at AppThwack)

Haha, good question. We did it via PMs or DMs or whatever the given site had. It also made it a bit more personal since we were using our own accounts.

When we were looking to fill up our private beta for AppThwack early last year we went to reddit, XDA, LinkedIn groups, and other places where we thought our target customers (Test engineers and app developers) would be. We posted non-spammy posts asking for beta testers and did not mention our product's name. We just described the problem we solved, how we were doing it, and asked for volunteers to sign up.

If I was doing it again I'd follow a similar path, but I'd also approach some of the more influential people in our target market and ask them directly for their help and feedback. We've done that with various features since and it's worked out great.

In addition to hardware capabilities and responsiveness mentioned by others, the performance data (CPU usage, memory usage, battery usage, etc) of a real device will be vastly different than the emulated version. In addition, emulators typically do not run manufacturer or carrier ROMs, meaning that the behavior on the emulator often differs from the actual device.

For testing initial layouts or on-the-fly development, emulators are fine because they offer instant local access (After the setup, of course, but who cares now that x86 emulators are so fast). For complete testing real devices are a must. That's traditionally been expensive, but there are solutions to that, such as the company I founded, AppThwack, and our competitors like TestDroid. Test locally on emulators, and test periodically on real consumer devices.

There's a reason nearly every development shop has a cupboard full of devices, and it's not because they couldn't figure out how to get a few emulators running.

Interesting that Sony was pretty takedown-happy a year ago and then seemingly went silent. Did something change? I can't imagine people stopped creating "infringing" content.

Also of note is the decompiled code with license info still intact, like 2012-07-16-microsoft.markdown. Seems like a dick move to put something like that on github, especially without even bothering to clean up the code or do something interesting with it.

I was there yesterday, and we actually presented and ended up tied for second place. AppThwack (Not to be confused with a "brain tumor") is a rapid, automated QA service for testing Android apps on real, non-emulated devices in a massively parallel and fast way. I realize it's not a world-changingly noble mission, but I also don't think it's trivial or inconsequential. Regardless, here are my thoughts. I posted a bit more in the article comment, but thought I'd paste part of my comment here.

"This article is definitely entertaining. It's vapid and catty and well written, and accurately portrays an event from an outsider's perspective. Of course there are lots of things that look like "bad ideas" on their face. On the other hand, there are lots of ideas that seem dumb at first that grow into interesting companies that end up solving legitimate problems.

Overall I think the event was very well run and I met a lot of great people. I was there with the goal of getting something out of it, though, and that something was connections, potential partners/customers, and some more pitch experience. Obviously the author got what he was looking for as well.

I think it's important that the "startup community" (I hate that that's a thing people say) gets kicked in the balls every now and then. For example, this look at TechCrunch Disrupt: http://www.buzzfeed.com/jackstuef/scenes-from-the-pounding-h...

The first time I say it out loud to someone there's often a request to hear it again. If they're a native speaker it generally clicks with an emphasis on "Thwack." If they're not, spelling it clears it up rather quickly. Usually it's because they've never heard the word before.

Once people get it they repeat it, likely because it's an entertaining and weird thing to say.

I agree with the advice that names should be easy to spell, but I also think it depends on context. Nearly all of our customer acquisition starts visually, either through the site, banners, or press, so it hasn't really been a problem.

Who knows if we'll keep it forever, but it's working for now.

The first time we publicly demoed AppThwack it was pointed out. On the other hand, people seem to remember it and generally react positively. Who knows if it will stick, but we agree on it enough for now that it's better to focus on the product and getting customers.

Thanks!

We've gone back and forth a ton of times, especially because of the obvious "Aflac" thing. We get a lot of comments that are positive, and of course some that are negative, but nobody seems to have a problem remembering it.

I'm way more concerned with providing a good product with a name that's "good enough." Also, it describes in slightly playful terms exactly what we do. We test apps.

As a counterpoint, my company was featured on TC this morning and we're boot-strapped and neither of us are even close to being rock stars. I realize we may be an exception to the rule, but it is possible for a young company (We started March 29th) to get noticed and picked up. It did take a lot of persistence and effort, but was definitely worth it.

If you're interested, here's the article: http://techcrunch.com/2012/07/03/appthwack-takes-on-android-...

Absolutely. We started out in very similar fashion, working on our product on the side and only quitting our day jobs when we absolutely had to to progress further.

For the first two months we regularly put in at least 12 hours a day seven days a week. We progressed, but towards the end of it we were barely recognizable. The amount of stress it put on us, our family, and our friends was immense. I'd drag myself to a bar to see friends and I'd spend most of the time zoning out, thinking about what I needed to work on as soon as I was back at home.

We've since forced ourselves to adopt a more structured approach, and factored in time to go fishing, play snooker, sing karaoke, or just relax. We're still working like crazy, but with a little bit of balance it no longer feels like the drudgery it had become before.