Blog posts are the main selling point of your product to developers. A developer will look at your blog posts to judge whether your product is worth investing in or not. Things like technical inaccuracies, marketing jargon, unnecessarily complicated or unclear writing will turn them away. You need solid articles that speak to developers. With over 5 years of development experience and more than 3 years of developer relations experience, I know exactly how to reach them.
What do I need from you?
- Topic
- The content type
- The audience
- Word count
- Deliverables
- Other information (what tools to use/not use, any specific message you want to send, CTA, etc.)
- Access to any paid tool you want me to use for the article. If you have an account with premium access, you can provide me with the credentials, or I can purchase an account and invoice you.
What will I deliver?
Highly polished technical articles
Content Types
I offer 4 different content types:
Tutorial
Tutorials are detailed and step-by-step guide that offers a hands-on experience to demonstrate how a product/feature works. A complete demo app is built and every step is detailed. Complete with a repo, screenshots, and code samples, this is very useful to showcase your product.
Read a sample here.
Guide
This is a high-level article that provides an overview of a topic. It may have code samples, but it’ll not be step-by-step. The code samples will be to show examples, but they’ll not provide a complete app. Useful to explain a topic related to your product and hook the developer with a CTA.
Read a sample here.
Listicle
Also known as Roundup, a listicle explores a bunch of tools/ideas/products and compares them. Each tool gets a small overview. Useful to compare your product with your competitors. Might have code samples to demonstrate features, but may not be complete code samples.
Read a sample here.
Comparison
Compares 2-3 product in details. Unlike listicles, the number of items is small, so each item can be described in more details. Use this to compare your product with your competitors.
Read a sample here.
Deliverables
Other than the articles, you can choose extra deliverables:
- Screenshots. Will be included where it makes sense by default.
- Code Samples. Will be included where it makes sense by default.
- Demo App. Only for tutorials and guides. Will be provided as a GitHub repo.
- Rough architecture diagram. I’ll draw a rough diagram. Note that I’m not a designer, so I can’t follow your brand guidelines. The diagram will be a rough drawing that you’ll need to convert to a final drawing (if you want).
Note: I have the right to omit a deliverable if it doesn’t make sense.
Other Information
Here are the other information you can choose:
Audience
The audience of your article. Be very careful while choosing this as this will set the tone and level of the piece. Be as specific as you can. For example “Full stack developers with 3-5 years of experience with React” instead of “React developers.”
Tools to Include/Exclude
Should I include or exclude any tool? For example: “Use React. Don’t use Next.js.” You can also specify the programming language of the codes.
Specific Message
Any specific message you want to send? For example “Position our product as easier to use than X.”
CTA
A call to action for the readers to try out your product.
Mention of Product
How much should I mention your product? You have 4 choices:
Don’t mention
I’ll not mention your product at all. Useful to discuss about a topic where your product has no presence, or if your CMS automatically inserts your product’s ad and you don’t want to mention it in the article.
Brief mention in conclusion
I’ll mention your product in the conclusion and in the CTA
Subtle mentions
Your product will be subtly mentioned throughout the article. Useful if you want to highlight your product without being aggressive with the marketing.
Focus on product
Your product is the focus of the article. For example, building an app with your product.
Revisions
Don’t like the article? Don’t worry! I’ll work with you to make it right. You’ll get three revisions for free. Still don’t like it? I’ll refund you!
But let’s be clear about the terms so that we don’t waste each others’ time:
- I’ll provide the revision as long as it’s within scope. If the revisions are out of scope, it’ll count as a separate article. Here’s a non-exhaustive list of out-of-scope changes:
- Changing the content type, e. g. change a guide to tutorial.
- Changing the tool, e. g. change the app from Python to JS
- Changing the mention of your product, e. g. wanting to focus on your product while initially you chose no mention.
- Adding or removing sections in the outline, e. g. add a new tool in a listicle
- Asking for a deliverable which wasn’t selected.
- Asking for major changes in the demo app.
- You’ll need to send the article for revision within 3 weeks. If you send for revision after 3 weeks, I’ll still provide 3 revisions, but I’ll not provide a refund if you’re not satisfied with the final article.
How Does it Work?
The process is easy, once you select a package, the work begins.
- You submit the topic and the details
- I create an outline for the article.
- If you want changes in the outline, you send it back for revisions.
- Once you approve the outline, you can’t change the details anymore. So, approve carefully.
- After all the outlines in the batch are approved, you pay me 40% of the total amount in advance.
- I start writing the article.
- If you want changes, you can send it back for revisions.
- If you approve the article, you can’t get revisions.
- After all the articles in the batch are approved, you pay the rest.