Craft and publish engaging content in an app built for creators.
Post on LinkedIn & Mastodon too. More platforms coming soon.
Make it punchier 👊
We're launching a Command Bar today with great commands and features.
AI ideas and rewrites
Get suggestions, tweet ideas, and rewrites powered by AI.
Turn your tweets & threads into a social blog
Give your content new life with our beautiful, sharable pages. Make it go viral on other platforms too.
Powerful analytics to grow faster
Easily track your engagement analytics to improve your content and grow faster.
Build in public
Share a recent learning with your followers.
Pose a thought-provoking question.
Never run out of ideas
Get prompts and ideas whenever you write - with examples of popular tweets.
I think this thread hook could be improved.
On it 🔥
Share drafts & leave comments
Write with your teammates and get feedback with comments.
Reply with "Notion" to get early access to my new template.
Create giveaways with Auto-DMs
Send DMs automatically based on engagement with your tweets.
And much more:
Auto-Split Text in Posts
Connect Multiple Accounts
Creators love Typefully
130,000+ creators and teams chose Typefully to curate their Twitter presence.
Tweeting more with @typefully these days.
✍️ Write-only Twitter
🧵 Effortless threads
📈 Actionable metrics
I recommend giving it a shot.
Typefully is fantastic and way too cheap for what you get.
We’ve tried many alternatives at @framer but nothing beats it. If you’re still tweeting from Twitter you’re wasting time.
This is my new go-to writing environment for Twitter threads.
They've built something wonderfully simple and distraction free with Typefully 😍
For 24 months, I tried almost a dozen Twitter scheduling tools.
Then I found @typefully, and I've been using it for seven months straight.
When it comes down to the experience of scheduling and long-form content writing, Typefully is in a league of its own.
Luca Rossi ꩜@lucaronin
After trying literally all the major Twitter scheduling tools, I settled with @typefully.
Killer feature to me is the native image editor — unique and super useful 🙏
Really impressed by the way @typefully has simplified my Twitter writing + scheduling/publishing experience.
Beautiful user experience.
Simplicity is the ultimate sophistication.
Queue your content in seconds
Write, schedule and boost your tweets - with no need for extra apps.
Schedule with one click
Queue your post with a single click - or pick a time manually.
Pick the perfect time
Time each post to perfection with Typefully's performance analytics.
Boost your content
Retweet and plug your posts for automated engagement.
Start creating a content queue.
Write once, publish everywhere
We natively support multiple platforms, so that you can expand your reach easily.
Check the analytics that matter
Build your audience with insights that make sense.
Writing prompts & personalized post ideas
Break through writer's block with great ideas and suggestions.
Never run out of ideas
Enjoy daily prompts and ideas to inspire your writing.
Use AI for personalized suggestions
Get inspiration from ideas based on your own past tweets.
Flick through topics
Or skim through curated collections of trending tweets for each topic.
Write, edit, and track tweets together
Write and publish with your teammates and friends.
Share your drafts
Brainstorm and bounce ideas with your teammates.
I think this thread hook could be improved.
On it 🔥
Get feedback from coworkers before you hit publish.
Read, Write, Publish
Control user access
Decide who can view, edit, or publish your drafts.
Another "so close and yet so far away" release from AWS
AWS needs to realize that:
1️⃣there's a world outside AWS
2️⃣not everybody has AWS' reliability requirements & profit margins
This could've been awesome, but no, AWS keeps repeating the same mistakes
To be fair, the Deployment Pipeline Reference Architecture (DPRA) gets *A LOT* of things right. Good job on that!
Seriously 👏 I especially like all the examples!
And there's a big need for something like this. I applaud AWS tackling this!
But then problems starts to appear...
Mean TLDR: no more OSS projects to run as a service? Let's make public services out of things we built internally.
Nooo, of course everybody has the same needs as AWS and of course everybody will just get it. No need to spend precious time productizing it! Bias for action!
Problem 0: it's not pretty or easy to read
Look, this is teaching material. We make teaching materials easy to read and pretty so folks can focus on the content and not go "huh?" and "wait what does that symbol mean?" and "there are colors here, do they mean different things?"
Problem 1: it's slow as heck with a target of "a couple hours"
AWS suggests that the pipeline should take 10 minutes for building, 1 hour for testing, and god-knows how long for the prod rollout.
So between 1 and ∞ hours 🤦♂️
Problem 2: it's pushing outdated expensive, hard-to-implement practices.
"But Vlad, not everybody has to be on the bleeding edge"
That is not what I am arguing for! CI/CD pipelines should be boring, I agree.
Let's dive a bit deeper!
TL;DR for problem 2: "wanna learn how to drive a car? Oh, no, no, nonono. First you must learn competitive running, and then cycling, and then horse riding. Learning those first will help you learn how to drive"
Hell no, that will be a HUGE time and money sink.
Example that highlights problem 2: the "Test" steps are outdated and gloss over exceedingly complicated problems.
"Test (Beta)" suggests creating test environments on demand.
Awesome. Sounds good.
Except it's a horror story with countless pitfalls. Worse, we *know* this and have known for years.
Oh, databases on demand?
Yeah, you need either golden images or seed scripts. Both need pipelines, care, and maintenance. And they're useless cause of course the data will always be nice and clean and perfect and not at all match any real environments.
Oh, are you running EKS?
HA, good luck trying to automate cluster creation, workload deployments, and cleanup. It's not impossible, but requires your firstborn and mountains of workarounds.
You'll waste YEARS of engineering time trying to create environments on demand.
And even if you succeeded, you're going to land into another ambush: they're expensive as heck and they create the worst cultural incentives. Your bill will explode and there won't be any easy fixes.
"Test (Gamma)" suggests having a "as production-like as possible" environment.
We know that is a lie. Prod-like environments don't exist: they're the spherical cow of the software world!
Staging environments are both useful and useless at the same time, so I'll give this a pass
But this is not how testing should be done today!
This is how we did testing when we only had basic building blocks (VMs and immutable infra), around 2014-ish.
We, as an industry, have seen this pattern fail over and over again. It does not work for most companies!
Most companies don't have AWS-levels of reliability requirements 🚨
Most companies can't afford creating 100s of environments a day 💰
Most companies don't have countless internal dev tools to make this process work and for most it does not make sense to have such teams 🛒♾️
So, what do high-performing teams do?
They invest in people & they use off-the-shelf software and tooling that enable them to move fast in a cost-effective way while at the same time improving the customer experience.
They build operable software and safely test in production!
Release each change in production under a feature flag and test it like that!
Seriously, it's a well-documented and mature practice. We've known for years how to do this. We have mature off-the-shelf tools for this since 2016!
Boring rolling deploy + feature-flag release = 🚀
Rolling deploys are shockingly simple and reliable when everything is behind a feature flag 😉
Rare, complex change? Blue/green: add a new deployment with a new URL that gets only specific traffic (controlled by upstream feature flags)!
Feature flagging for releases!
- safer ▶️ rollbacks are done in seconds instead of minutes
- more reliable ▶️ no always-clean databases and envs
- cost-effective ▶️ no creating 20 servers to test a typo
- better for the customer ▶️ targeted previews and rollouts
I am not saying folks should not have the ability to create environments on demand: that should definitely still be a thing!
But it should be manual and rare: only done for rare intense changes or specific testing that demands *this level of effort*.
Getting back to DRPA's problems, Problem 3: it glosses over vital topics.
There's barely any discussion of local development or versioning.
Gitpod, Codespaces, Cloud9(🤣)? Tilt, Telepresence? GitOps?
These are complex, highly debated topics that are just... ignored.
AWS' Deployment Pipeline Reference Architecture sets folks up for failure.
Even if you somehow succeed, you'll find yourself with a sluggish, expensive, unmaintainable mess.
Worse, this will traumatize a whole new generation of developers and ruin a whole new batch of companies
AWS' Deployment Pipeline Reference Architecture, in its current form, is a recipe for disaster.
There is a desperate need for a reference architecture and more documentation, but this is not it.
Since I know I'll be spammed: I have no open slots for this type of work, but David Raistrick is an awesome consultant that can help with this!
Reach out to him on LinkedIn: linkedin.com/in/draistrick