Forem: Karl L. Hughes

DNS Propagation Doesn't Have to Take 24 Hours

Karl L. Hughes — Fri, 13 Feb 2026 11:26:11 +0000

You've probably been there. You update an A record in your DNS dashboard, then refresh your browser three times in a row. Nothing. Still showing the old server.

Then someone in a different timezone messages you saying they can see the new version. But you can't. You check again. Still nothing.

Someone on your team says, "Don't worry, DNS takes 24-48 hours to propagate."

I used to accept this waiting period as normal. It's not. DNS changes don't take 24 hours because the internet is slow. They take that long because someone left a default or high TTL value on the A record and never thought about changing it.

"Propagation" isn't some mysterious internet ritual. In reality, it's just a cache that expires. And here's the thing: you control the expiry timer. Set your A record’s TTL to 300 seconds (name.com's standard minimum) before making changes, and you're looking at minutes, not days.

In this post, I'll explain how DNS caching actually works, how to use TTL values strategically, and how to make infrastructure changes without any downtime.

What "Propagation" Really Means

When you update a DNS record at name.com, the change takes effect immediately on name.com's authoritative nameservers. There's no delay on their end.

The lag you experience isn't happening on name.com's infrastructure. It's everywhere else.

The internet doesn't work by constantly checking name.com's DNS servers for your latest DNS records. That would create millions of unnecessary queries every second. Instead, DNS uses a layered caching system.

When someone requests your domain, their query goes through a recursive resolver first. This resolver checks its local cache before reaching out to authoritative servers. If the record is cached, the resolver just returns that cached value without ever contacting name.com.

That's your bottleneck. "DNS propagation" is really just waiting for cached records to expire across thousands of recursive resolvers around the world.

The Two Types of DNS Servers

Authoritative nameservers are where your actual DNS records live. When you manage DNS records in the name.com dashboard, you're modifying data on name.com's authoritative servers (ns1.name.com through ns4.name.com). Changes here happen instantly. Update an A record and it's live on the authoritative server in seconds.

Recursive resolvers are intermediary servers run by ISPs, network administrators, or public DNS providers like Google (8.8.8.8) and Cloudflare (1.1.1.1). When your browser needs to resolve a domain name, it asks a recursive resolver. That resolver either returns a cached answer or queries the authoritative server on your behalf. Then it caches the result for future requests.

Your users aren't querying name.com's authoritative servers directly. They're hitting recursive resolvers that might have stale cache. The "propagation period" is just the time it takes for those cached entries to reach their expiration.

TTL: Your Control Mechanism

TTL (Time To Live) is measured in seconds and gets attached to every DNS record. It tells recursive resolvers how long they can trust the cached data before asking again.

An A record with a TTL of 3600 means "you can cache this IP address for one hour."

When you change that A record's IP, resolvers that previously cached it won't see the change until their cached copy expires. If your TTL was 86400 seconds (24 hours), some resolvers might not pick up the new IP for a full day.

That's where the "DNS takes a day to propagate" myth comes from. It's not a limitation of DNS. It's just a consequence of how you've configured it.

Lower the TTL to 300 seconds (5 minutes), and the maximum cache duration drops to 5 minutes. Most resolvers respect TTL values. They'll query the authoritative server again once the timer runs out. This is how you compress propagation time from hours to minutes.

name.com enforces a 300-second minimum TTL on most record types to keep the global DNS infrastructure stable. You can't go lower than that, but 5 minutes is fast enough for most situations.

The trade-off is query volume. Shorter TTLs mean more frequent queries to authoritative servers, which slightly increases load. For most sites, this difference doesn't really matter.

The Problem Nobody Talks About: Negative Caching

There's another type of caching that catches people off-guard during new site launches.

If someone visits your domain before you've configured DNS records, their resolver gets an NXDOMAIN response (domain doesn't exist). That negative response gets cached too.

The cache duration for negative responses is controlled by the SOA record's negative TTL field, which is often set to several hours. According to RFC 2308, the negative TTL is determined by the minimum of the SOA MINIMUM field and the SOA TTL. This can be much longer than your A record's TTL.

Here's the scenario: You register a domain. Someone checks if it's live before you finish setting it up. They get NXDOMAIN. Their resolver caches that negative answer for hours.

When you finally configure the DNS records, that person still can't access your site. Their resolver isn't checking again because it has a valid (though incorrect) cached negative response.

I've seen this mess up coordinated launches. You announce a new site, people check immediately, get NXDOMAIN, and then report "the site doesn't work" even after you've configured everything correctly.

The fix is simple: configure all DNS records before announcing anything publicly. Don't give resolvers a chance to cache a negative response in the first place.

How to Choose the Right TTL

You shouldn't always use the lowest possible TTL. High TTLs reduce query load on authoritative servers, improve response speed (cached lookups are faster than fresh queries), and give you some resilience if your DNS provider has a temporary outage.

Low TTLs give you agility but generate more traffic to authoritative servers.

The right TTL depends on how stable your infrastructure is and how often you make changes:

Use 86400 seconds (24 hours) or higher when:

Your infrastructure is stable and changes are rare
You want maximum efficiency on DNS query costs
You're running a static site that won't move servers
You need DDoS protection (cached records reduce attack surface)

Use 300-600 seconds (5-10 minutes) when:

You're planning a migration or deployment soon
You need rapid failover for high-availability setups
You're in a development environment with frequent changes
You want the ability to quickly roll back if something breaks

Use 3600 seconds (1 hour) for most production sites. It's the sweet spot. Changes take effect within an hour, which is fine for most situations, and query volume stays reasonable.

The pattern I use for controlled migrations: run with a high TTL during normal operations, drop to 300 seconds at least 48 hours before planned changes, do the migration, verify everything works, then raise the TTL back up.

This keeps the query load low most of the time while giving you precise control when it matters.

How to Migrate With Zero Downtime

A true zero-downtime migration means both the old and new servers need to serve traffic at the same time during the transition. You can't control which resolver has cached which IP, so both IPs need to return valid responses.

Phase 1: Preparation (48 Hours Before)

Log into the name.com DNS management interface and find the DNS record you're going to change. Note the current TTL value.

If it's higher than 300 seconds, change it to 300 seconds now.

Then wait. The wait time needs to be at least as long as the previous TTL value. If your A record had a TTL of 86400 seconds, you need to wait 24 hours. I usually wait 48 hours to be safe.

This ensures that all resolvers that cached your record at the old, higher TTL will have their cache expire before you make the switch.

You really can't skip this step. If you do, you're back to unpredictable propagation times measured in hours or days.

Phase 2: Set Up Both Servers

While you're waiting for old TTL caches to expire, get your new server ready. Deploy your application, configure your web server (nginx, Apache, Caddy, whatever you use), and install SSL certificates.

Test the new server by hitting it directly via IP address or by temporarily modifying your local /etc/hosts file to point your domain at the new IP.

Here's the critical part: don't shut down the old server. It needs to stay running.

During the transition, users will hit either the old or new server depending on which IP their resolver has cached. Both need to work.

For apps with databases, make sure both servers can access the same database or that you've synced the database state between them. For stateless applications, this is easier. Just make sure both servers have the same code and configuration.

Phase 3: Make the DNS Change

After 48 hours have passed and your new server is tested and ready, update the DNS record.

In the name.com dashboard, change the A record IP address from the old server to the new server. Double-check that the TTL is still 300 seconds. Save it.

The change is live on name.com's authoritative servers immediately. Now you're in the transition window.

For the next 5-10 minutes, some users will hit the old server (cached IP) and some will hit the new server (fresh DNS query). Both work, so nobody sees downtime.

Phase 4: Verify Everything

Don't trust your browser. Don't trust a single ping command. You need to check propagation across multiple public DNS resolvers to get a real picture.

Use the dig command (or nslookup on Windows) to query specific resolvers:

# Query Google's public DNS
dig @8.8.8.8 yourdomain.com A

# Query Cloudflare's public DNS  
dig @1.1.1.1 yourdomain.com A

# Query Quad9
dig @9.9.9.9 yourdomain.com A

Look at the "ANSWER SECTION" in each response. If all resolvers return the new IP address, you're done. If they're mixed (some returning the old IP, some returning the new), you're still in the transition window. Wait a few minutes and check again.

You can also use web tools like whatsmydns.net to check DNS resolution from multiple locations around the world at once. This gives you a visual confirmation that the change has spread globally.

If something goes wrong and you need to roll back, just update the A record back to the old IP. With a 300-second TTL, the rollback will take effect within 5 minutes. That's your safety net.

Phase 5: Clean Up

Once you've confirmed that propagation is complete and traffic has fully moved to the new server (check your old server's logs to make sure it's not getting any more requests), you can raise the TTL back to a normal value. This reduces ongoing query load.

I usually wait 24 hours after migration to make sure everything is stable, then edit the DNS record and change the TTL from 300 seconds to 3600 seconds (1 hour) or 86400 seconds (24 hours).

Only after the new server is stable and the TTL has been raised should you shut down the old server.

Tools for Verification

The dig command is the standard tool for DNS debugging. It comes installed by default on most Unix-like systems (Linux, macOS) and you can get it on Windows through BIND utilities.

Basic syntax:

dig yourdomain.com

This queries your system's default resolver. To query a specific resolver, use the @ syntax:

dig @8.8.8.8 yourdomain.com

To see the full path including all the intermediate nameservers, use the trace option:

dig +trace yourdomain.com

The trace option shows each step: root nameservers, TLD nameservers, authoritative nameservers. This helps you figure out where in the DNS chain something is breaking.

For quick checks during a migration, I like to make a simple shell script that queries multiple resolvers and compares the results:

#!/bin/bash
DOMAIN=$1
RESOLVERS="8.8.8.8 8.8.4.4 1.1.1.1 1.0.0.1 9.9.9.9"

echo "Checking DNS propagation for $DOMAIN"
echo "========================================"

for resolver in $RESOLVERS; do
    result=$(dig +short @$resolver $DOMAIN A)
    echo "$resolver: $result"
done

Save this file as check_dns_propagation.sh, give it “execute” permissions (chmod +x check_dns_propagation.sh) and then run it like this:

./check_dns_propagation.sh yourdomain.com

Run this every few minutes after making the DNS change. When all resolvers return the same IP, you're done.

On Windows, you can do something similar with the nslookup command. Just add the resolver as a second parameter:

nslookup yourdomain.com 8.8.8.8

The output looks a bit different than dig but you can still just look for the new IP address you're expecting to see in your A record.

More Advanced Scenarios

Using CNAME Records

CNAME records point one domain name to another. They're useful when you want multiple domain names to resolve to the same place, and you want to update them all by changing a single A record.

But CNAME records have limits. RFC 1034 doesn't allow CNAMEs at the apex domain (example.com). You can only use them for subdomains (www.example.com, blog.example.com, etc.). For apex domains, you need A records or ANAME records if your provider supports them.

When you use CNAMEs, pay attention to TTL values on both the CNAME record and the target A record. A resolver caches both. Even if your CNAME has a 300-second TTL, if the target A record has an 86400-second TTL, you won't see changes for 24 hours.

MX Records for Email

MX records tell email servers where to deliver mail for your domain. When you migrate email services, the same TTL rules apply. Lower the MX record TTL to 300 seconds before migration, make the change, wait for propagation, then raise it back up.

Email has a built-in retry mechanism that helps here. If email delivery fails, the sending server will try again later. This gives you some forgiveness during email migrations, but you still want to keep the window of inconsistent MX records as short as possible.

Using the API for Automation

For infrastructure-as-code workflows or automated failover systems, name.com has an API for DNS management. You can create, update, and delete records programmatically.

This lets you do things like:

Run automated health checks that update A records when a server goes down
Write blue-green deployment scripts that switch DNS between environments
Set up dynamic DNS for services running on infrastructure with changing IPs

The name.com API documentation covers authentication, rate limits, and has example requests. Most DNS operations complete within seconds, which makes API-driven updates practical for production automation.

Final Thoughts

DNS propagation is really just cache expiring using a timer you control.

The "24-48 hour wait" is a leftover from default TTL settings that nobody bothered to change. Lower your TTL to 300 seconds before making changes, do the switch while keeping both old and new infrastructure running, verify propagation across multiple resolvers, then raise the TTL back up once things are stable.

name.com gives you what you need: authoritative nameservers with 300-second TTL minimums, a straightforward interface for managing records, and API access for automation. The rest comes down to how you execute.

Plan your changes, adjust TTLs ahead of time, keep dual-serving capability during transitions, verify completion, then clean up. This works for any DNS record type, any size infrastructure, and any complexity of deployment.

The underlying mechanism is always the same: control the cache timer, and you control the migration timeline.

I'd love to hear about your DNS migration experiences. Have you run into the "24-48 hour propagation" problem? What's the longest you've waited for DNS changes to take effect? Let me know in the comments.

Measuring AI's Real Impact on Your Engineering Team

Karl L. Hughes — Wed, 03 Dec 2025 17:52:42 +0000

A few months back, the tech world got hit with a wave of panic-inducing headlines. CEOs and tech leaders were on stages everywhere claiming that massive percentages of their code was now AI-generated. If you weren't on board, you were basically toast.

This kicked off what I can only describe as a spending frenzy. Companies started signing six and seven-figure contracts for AI coding tools, desperate not to fall behind. The question everyone was asking was simple: "How do we get our entire team using AI?"

Now? The conversation's changing. The companies that jumped in early are starting to ask a much harder question: "Is this actually worth it?"

We've moved past the hype cycle into the messy reality of execution. Instead of "Are we using AI?" teams are asking "Are we using it well?" And here's the problem: the metrics we've relied on for years to measure engineering productivity? They're completely inadequate for this new world.

Why Your Current Metrics Are Lying to You

Trying to measure AI's impact with traditional engineering metrics is like trying to figure out how fuel-efficient your Tesla is by checking its oil consumption. The engine's changed completely, so the gauges you're looking at are basically useless.

Cycle Times That Mislead

Your cycle time might drop by 50%, and you'll celebrate. But here's what's really happening: AI shortened your coding phase dramatically, but the code it generated is so convoluted that your review phase doubled in length. You haven't actually gained anything. You've just moved the bottleneck somewhere else in your pipeline.

Traditional tools can't see this shift, so you end up celebrating a vanity metric while your team drowns in review friction.

DORA Metrics That Can't Diagnose

Don't get me wrong, DORA metrics are great for measuring overall pipeline health. But they're too high-level to tell you anything specific about AI's impact. Your Change Failure Rate goes up, and DORA just shrugs. It can't tell you if that's because of poorly-written AI prompts, bad code quality from your AI tool, or something completely unrelated to AI at all.

It's a smoke alarm that can't tell you where the fire actually is.

Lines of Code (Still Terrible)

Lines of code has always been a terrible metric, but AI makes it completely absurd. An AI tool can spit out thousands of lines in seconds. Measuring productivity this way is worse than useless because it actively rewards the wrong behavior.

A Better Framework for Measuring AI ROI

An engineering organization is fundamentally a system: you put things in (headcount, tools, cloud spend) and you get things out (a working product). A real framework for measuring AI ROI has to connect these inputs to outputs in a meaningful way.

Here's how to think about this in stages, from basic to sophisticated. I've broken it down into four pillars that every team needs to address.

Pillar 1: Measure Real Engineering Velocity

This is where everyone starts, because the core promise of AI is speed. Your job is to quantify that speed objectively.

Start Simple: Track Basic Output

First, just measure throughput. Look at pull requests merged per week or issues resolved. This gives you a baseline of what your team is actually shipping.

Get More Sophisticated: Understand How Work Gets Done

Next, you need to understand the mechanics of that work. Start tracking your AI Code Ratio, which is just the percentage of your merged code that came from AI. At the same time, analyze your team's calendars to see if AI is actually freeing up engineers for more focused work, or if they're still spending all their time in meetings.

The Gold Standard: Segment by AI Usage

The ultimate goal here is to connect AI usage directly to outcomes. Segment your cycle time metrics by how much AI was used in each pull request. This lets you answer the most important question: "Are PRs with lots of AI-generated code actually moving through our system faster than human-written code?"

Pillar 2: Measure Quality and Maintainability

Speed without quality is just technical debt with a stopwatch. This pillar measures the hidden costs you're accumulating.

Start Simple: Track Your Change Failure Rate

Begin with your Change Failure Rate. It's a lagging indicator, but it gives you a good sense of how many deployments are breaking things in production.

Get More Sophisticated: Look at Rework and Complexity

A more proactive approach is tracking your Rework Rate, which is the percentage of code that gets rewritten shortly after being merged. Are your AI-heavy PRs more brittle than human-written code? At the same time, start measuring code complexity. Is the AI generating clean, maintainable code, or is it creating unreadable messes that will haunt you for years?

The Gold Standard: Track Defects by AI Dosage

The real test of quality is measuring your Defect Escape Rate for AI-generated code versus human-written code. This requires patience, you'll usually need about 90 days post-deployment to see meaningful patterns, but it gives you the definitive answer on whether AI is improving or degrading your customer experience.

Pillar 3: Measure Organizational Impact

AI's impact goes way beyond your codebase. It changes your team dynamics and your culture.

Start Simple: Track Who's Using the Tools

First, just measure adoption. Who's actually using your AI tools? Track weekly active usage across your organization to see which teams are leaning in and which ones are holding back.

Get More Sophisticated: Measure Onboarding Speed

One of AI's big promises is that it helps people learn faster. Start measuring Time to 10th PR for new engineers. Is AI actually helping them become productive members of the team sooner?

The Gold Standard: Assess the Talent Pipeline Risk

Here's something most teams miss: AI is automating a lot of the simple, repetitive work that used to be the training ground for junior engineers. This creates a real long-term risk. Are you accidentally eliminating the path from junior to senior engineer? This is harder to quantify, but it's critical for any serious ROI discussion.

Pillar 4: Measure Total Cost

Once you understand velocity, quality, and organizational impact, you can finally connect everything to cost.

Start Simple: Compare License Costs to Headcount

The most basic analysis is just comparing your annual spend on AI tools to what you'd pay for an additional engineer.

Get More Sophisticated: Track Token Usage

Next, start tracking token consumption. Which teams or engineers are power users? Where are you burning through credits the fastest?

The Gold Standard: Automate R&D Capitalization

The most advanced approach is using AI to automatically classify your engineering work into categories like "New Feature," "Maintenance," or "Infrastructure." This lets you generate automated R&D cost capitalization reports for finance, turning your engineering data into a strategic business asset.

Building the Right Culture Around Metrics

A framework doesn't matter if your team doesn't trust it. Engineering metrics can be incredibly valuable, but if you implement them poorly, you'll just create fear and mistrust.

Be Transparent About What You're Measuring

The "why" matters more than the "what." Tell your team openly what you're measuring and why. Frame it as a tool for finding and fixing systemic problems, not for micromanaging individuals.

Focus on Systems, Not People

Use metrics to understand the health of your development process, not to create a performance leaderboard. The question should be "Is our system working?" not "Who's the fastest coder?"

Start Conversations, Don't End Them

Metrics should kick off discussions, not close them. If review times are spiking for a team, don't just demand they move faster. Ask what's getting in their way. Is the process too complex? Is the code too hard to understand?

The Surprising U-Shaped Curve

When you actually implement this framework, you'll find some counterintuitive patterns. We've seen one trend consistently across nearly every team we work with: the impact of "hybrid" AI usage.

You might assume that PRs with 100% AI-generated code are the riskiest, but the data shows something different. PRs with a mixed bag of 25-50% AI-generated code consistently cause the most rework and review friction.

This actually makes sense when you think about it. When a developer uses AI as pure autocomplete, mixing human logic and AI logic throughout a PR, it creates cognitive whiplash for the reviewer. They're constantly switching between evaluating two different "minds," and that's exhausting. A PR that's clearly all-human or all-AI is often much easier to review.

One team I worked with was dealing with a massive code review bottleneck. By analyzing their AI Code Ratio on each PR, they found that a small group of engineers was creating most of these high-friction hybrid PRs. It wasn't a performance issue, it was a training issue. After coaching the team on better prompt engineering to generate more complete PRs, they cut their average review time by nearly 30%.

The Economic Reality Coming Your Way

This level of measurement is becoming urgent because the economics of AI are about to change dramatically. Right now, most AI tools aren't profitable. They're being subsidized by venture capital to drive adoption, just like AWS did in the early days of cloud computing.

Remember what happened next? An entire FinOps industry emerged to help companies optimize their cloud spend. The same thing is coming for AI. As these tools get more expensive, you're going to face hard trade-offs. The question will be: "Do I spend my next $100,000 on more AI licenses, or do I hire another engineer?"

Without objective data on ROI, you're just guessing.

Questions We Still Can't Answer

We're still early in this story. While we can now measure velocity, quality, and cost, a new set of long-term questions is emerging that nobody has solved yet.

For example, people care about code readability today, but will they in three years? If an AI can interface directly with code, does human readability even matter? In a sense, English is becoming the new programming language. We care about the English prompt, we don't care about the compiled assembly code. This is a fundamental shift in abstraction, and we don't yet know what it means long-term.

What I do know is that leaders are going to need new signals for velocity, quality, and maintainability in this AI-native world. The best place to start is by building a framework to measure what's happening right now. Move past the hype, implement a real approach to measuring ROI, and you'll be able to navigate this transformation with actual data instead of just following the crowd.

Next Steps

Ready to move beyond guesswork and start measuring AI's real impact on your engineering team? Here are concrete actions you can take:

Get Ground Truth on AI Usage: Start by understanding what percentage of your codebase is actually AI-generated. Span's AI Code Detector provides 95% accurate detection of AI vs. human-authored code, giving you the foundation for all other measurements. This is your baseline, the ground truth you need before making any strategic decisions about AI tooling.

Build a Complete Measurement Framework: Rather than cobbling together disparate tools and spreadsheets, consider a unified developer intelligence platform that connects AI detection to velocity metrics, quality indicators, and team dynamics. The right platform should automatically track your AI Code Ratio, segment outcomes by AI usage, and surface patterns like the U-shaped curve described above.

Understand What Metrics Can and Can't Tell You: Before diving deeper into measurement, learn why perception-based approaches like surveys fall short when measuring AI impact. Understanding the limitations of different measurement approaches will help you avoid common pitfalls and build a more robust framework from the start.

See a Demo of Production-Ready AI Measurement: If you're ready to implement a comprehensive AI measurement strategy without building it from scratch, schedule a demo to see how leading engineering teams are measuring and optimizing their AI coding initiatives.

Best Developer Productivity Tools for Engineering Leaders: A 2025 Guide

Karl L. Hughes — Mon, 17 Nov 2025 15:11:05 +0000

The market for developer productivity tools has become increasingly crowded and confusing, with platforms measuring wildly different metrics, from DORA metrics to developer happiness surveys. Each vendor promises to be the silver bullet for engineering efficiency, but the reality is far more nuanced.

As engineering teams scale, leaders face a critical challenge: losing direct visibility into what’s actually happening on the ground. Without the ability to pop into every standup or review every pull request, engineering leaders need objective, comprehensive data to identify real bottlenecks, measure the impact of new technologies like AI, and make confident decisions about their teams and processes.

This guide evaluates the leading developer productivity platforms against four critical criteria that modern engineering leaders should prioritize when selecting a tool for their organization. These platforms were chosen based on their market presence, feature maturity, and ability to address the complex needs of scaling engineering teams. Each tool offers a different approach to the challenge of measuring and improving developer productivity.

The Four Critical Criteria for Modern Engineering Leaders

Before diving into specific tools, it’s important to understand the evaluation framework. These four criteria represent the most pressing needs for engineering leaders navigating today’s rapidly evolving technology landscape:

AI-Native Capabilities: Does the platform leverage AI to deliver automated insights and reduce manual work?

Comprehensiveness of Insights: Does it provide a complete view covering delivery speed, code review processes, developer experience, and critically, AI adoption and impact metrics?

Ease of Use and Time to Value: How quickly can teams see meaningful, actionable data with minimal setup? The best tools deliver insights in weeks, not months and don’t require a lot of manual data manipulation to deliver value.

Enterprise-Ready Controls: Does it provide the granular roles and permissions needed to scale securely across different organizational levels?

The Leading Developer Productivity Tools

1. Span

Span represents the new generation of engineering intelligence platforms, built from the ground up to address the challenges of modern, AI-augmented development teams.

AI-Native Capabilities: Built with LLMs at its core, Span uses AI to reason over unstructured data, providing automated summaries and intelligent work classification without requiring perfect data hygiene. The platform can understand context from commits, PRs, and tickets to automatically categorize work and surface insights. This AI-first approach means teams get valuable intelligence immediately, without months of setup or process changes.

Comprehensiveness of Insights: Span provides a truly holistic view across delivery metrics, PR cycles, meeting load, and uniquely, AI adoption and impact metrics. The platform includes advanced detection for AI-generated code with its AI code detector, allowing it to correlate AI tool usage with productivity outcomes. This comprehensive coverage extends from individual developer insights to executive-level strategic views, making it valuable across all organizational levels.

Ease of Use and Time to Value: Leveraging AI to avoid process overhead, Span delivers out-of-the-box reporting and insights within weeks rather than months. The platform adapts to existing workflows rather than forcing teams to change their processes. Automated categorization and intelligent defaults mean teams see valuable insights from day one, with the ability to refine and customize as they learn what matters most to their organization.

Enterprise-Ready Controls: Span offers robust, granular roles and permissions designed for secure adoption from individual contributors to executives. The platform provides different views and access levels based on role, ensuring appropriate transparency. As a relatively newer player in the market, Span is gaining significant traction among startups and growth-stage companies. It lists many "hot" tech companies like Ramp and Vanta as customers. While it does serve large enterprises, it often takes more time for younger platforms to win over the largest organizations with thousands of engineers and highly specific internal requirements.

2. LinearB

LinearB positions itself as a platform focused on engineering benchmarks and predictable delivery, with strong appeal to engineering leaders who prioritize data-driven decision making.

AI-Native Capabilities: LinearB uses GitStream workflow automation to streamline development processes, such as applying custom rules to pull requests, assigning reviewers, or enforcing quality gates directly within Git. While powerful for process automation, its intelligence relies on user-defined YAML configurations rather than adaptive learning or predictive analytics. As a result, while it effectively automates routine tasks, its analytical capabilities remain relatively basic compared to newer AI-driven engineering analytics tools that leverage machine learning for deeper insights and proactive recommendations.

Comprehensiveness of Insights: LinearB excels in DORA metrics and delivery benchmarking, providing detailed comparisons against industry standards. The platform offers strong visibility into cycle time, deployment frequency, and team performance metrics. However, its focus on traditional metrics means less coverage of emerging areas like AI tool adoption or more nuanced developer experience factors.

Ease of Use and Time to Value: While LinearB provides extensive benchmarking data, the granularity can overwhelm teams new to metrics programs. Some advanced reporting features require engagement with their sales representatives, which can slow down adoption. Teams often report needing several weeks to configure the platform properly and additional time to train team members on interpreting the dense data visualizations.

Enterprise-Ready Controls: The platform is designed primarily for team-level engineering leaders—such as VPs of Engineering, team leads, or delivery managers—rather than for broad, enterprise-wide deployment across multiple departments or business units. While it does include basic role-based access control (RBAC) features, these are relatively limited in scope. Users can typically assign roles such as admin, manager, or contributor, but the permission structure doesn’t allow for fine-grained distinctions within those roles. For example, it lacks support for custom role creation, field-level permissions, or hierarchical access where directors might oversee multiple teams without viewing sensitive project data from unrelated groups. This makes it suitable for small to mid-sized teams that share unified visibility but less ideal for larger organizations that require more granular controls over data access, reporting, and visibility across multiple layers of stakeholders.

3. Jellyfish

Jellyfish targets CTOs and VPs of Engineering at large enterprises, focusing on aligning engineering work with business objectives through resource allocation visibility.

AI-Native Capabilities: Jellyfish employs an inference engine to reduce the burden of Jira hygiene, automatically categorizing work based on patterns. However, the platform isn’t focused on using AI for deeper work classification or providing AI-generated insights. The inference engine helps with basic categorization but doesn’t leverage modern LLMs for understanding work context or generating recommendations.

Comprehensiveness of Insights: The platform shines in allocating engineering investment, providing executives with clear data for DevFinOps use cases and capital and operational expense (CapEx/OpEx) reporting. It excels at answering the question, “How much did we spend on new product features versus maintenance?” However, this financial focus means less comprehensive coverage of granular code quality or AI adoption metrics. Jellyfish provides excellent visibility into where teams spend their time and how that maps to strategic initiatives. However, this focus on allocation means less comprehensive coverage of other critical areas like code quality, developer experience, or emerging metrics around AI tool usage.

Ease of Use and Time to Value: Jellyfish requires rigorous process hygiene to function effectively, particularly around Jira ticket management and categorization. This requirement leads to a longer time-to-value, often taking months rather than weeks to see meaningful insights. Organizations need to invest significant change management effort to ensure teams maintain the data quality needed for accurate reporting.

Enterprise-Ready Controls: The platform primarily serves executive-level leaders, with limited functionality for individual contributors or team-level managers. This top-down approach can create information asymmetry within organizations, where executives have visibility that isn’t shared with the teams doing the work. This can lead to a sense of being monitored, fostering mistrust among developers regarding the misuse of metrics.

4. DX

DX takes a research-driven approach to the market, combining quantitative metrics with qualitative survey data to provide a complete picture of developer productivity and experience.

AI-Native Capabilities: DX offers limited AI capabilities, primarily focused on automated summaries and basic classification of development effort. While the platform can generate some insights automatically, it doesn’t leverage AI extensively for pattern recognition or predictive analytics. The AI features feel more like additions rather than core to the platform’s value proposition.

Comprehensiveness of Insights: DX’s unique strength is its focus on the SPACE framework, combining system data (e.g., build times, PR latency) with customizable developer surveys. This allows leaders to correlate quantitative bottlenecks with qualitative feedback, providing valuable context on issues like burnout or tooling friction. This dual approach offers valuable context that pure metrics platforms miss, though it requires more effort to synthesize insights from multiple data sources.

Ease of Use and Time to Value: The platform’s strength in customization becomes a weakness for time to value. DX requires heavy setup and manual configuration to tailor it to an organization’s specific needs. Teams need to design surveys, configure metrics, and establish baselines before seeing valuable insights. The high level of customization means significant upfront investment before realizing value.

Enterprise-Ready Controls: While DX offers customizable reporting, the focus is less on granular role-based access controls. The platform provides flexibility in what to measure and report, but doesn’t offer the sophisticated permission structures needed for large organizations with complex hierarchies and varying transparency requirements.

5. Swarmia

Swarmia targets full engineering organizations, from individual developers to CTOs, with a focus on improving developer productivity through actionable insights and automation.

AI-Native Capabilities: AI features are not a core part of Swarmia’s offering, which focuses more on workflow automation and notification systems. The platform excels at surfacing relevant information through Slack but doesn’t use AI to generate insights or understand work patterns. The automation is rule-based rather than intelligent, limiting its ability to adapt to unique team contexts.

Comprehensiveness of Insights: Swarmia is designed to be a developer-first tool, focusing on improving team-level working agreements and habits directly within Slack. It provides real-time feedback on metrics like PR size and review times to help teams self-correct, though it offers less of a top-down, strategic view for executive-level investment tracking. However, it lacks depth in areas like AI tool adoption, investment allocation, or more sophisticated engineering intelligence metrics.

Ease of Use and Time to Value: Designed for quick adoption within teams, Swarmia shines in its Slack integration and intuitive interface. Teams can start receiving valuable notifications and insights within days of setup. The platform prioritizes actionable alerts over comprehensive dashboards, making it easy for teams to understand and act on the information provided.

Enterprise-Ready Controls: Swarmia lacks the robust roles and permissions structure needed for safe, scalable deployment in large organizations. While it works well for smaller teams with flat hierarchies, enterprises requiring different visibility levels for ICs, managers, and executives may find the platform limiting. The lack of granular controls can be a dealbreaker for security-conscious organizations.

6. Pluralsight Flow

Pluralsight Flow (formerly GitPrime) represents the traditional approach to developer productivity metrics, offering a safe, conventional choice for large organizations.

AI-Native Capabilities: Flow emphasizes rule-based and report-driven visibility rather than AI-native insights. The platform provides extensive dashboards and reports but doesn’t leverage AI for pattern recognition, automated classification, or predictive analytics. This traditional approach means more manual analysis work for engineering leaders trying to extract actionable insights from the data.

Comprehensiveness of Insights: Flow focuses on “classic” code-level metrics that predate the DORA framework, such as Code Churn, Impact, and Efficiency. While these can offer a deep view into the codebase itself, the platform offers less coverage of modern concerns like AI adoption or correlating work to broader business initiatives. While it integrates with standard tools like GitHub, Bitbucket, Jira, and Azure DevOps, it lacks coverage of modern concerns like AI adoption, investment allocation, or nuanced developer experience metrics. The platform feels comprehensive for yesterday’s challenges but incomplete for today’s.

Ease of Use and Time to Value: Users frequently report that Flow’s dashboards can be noisy and overwhelming, making it time-consuming to locate relevant information. The abundance of reports and metrics without intelligent prioritization means teams spend significant time learning to navigate and interpret the platform. Despite being a mature product, the user experience hasn’t evolved to match modern expectations for clarity and actionability.

Enterprise-Ready Controls: As a conventional choice backed by Pluralsight’s enterprise credibility, Flow offers standard enterprise features including SSO and basic role-based access. The availability of consulting services through Pluralsight can help with implementation, though this often indicates the platform’s complexity. While safe for procurement, it may not satisfy teams looking for modern, flexible permission structures.

Making the Right Choice for Your Organization

Choosing the right developer productivity platform is not about finding a single “best” tool, but about aligning a platform’s strengths with your organization’s most critical challenges. As this guide has shown, the leading tools have made different trade-offs: some prioritize financial reporting, others focus on developer-first workflows, and a new generation is being built for the complexities of the AI era.

For organizations ready to embrace the future of engineering intelligence, platforms built with AI at their core offer significant advantages in terms of ease of adoption, depth of insights, and ability to measure what truly matters in modern software development. The ability to understand AI’s impact on your engineering organization is no longer optional, it’s essential for making informed decisions about tool investments, team structure, and development practices.

Choosing a developer productivity platform requires a clear understanding of your primary goals. If your main objective is to align engineering costs with high-level business strategy, a platform like Jellyfish offers powerful tools for that purpose. If you are focused on improving developer-first habits within Slack, Swarmia excels in that specific area.

However, the landscape is rapidly evolving, and for many leaders, the most critical challenge is navigating the AI transformation. This requires a new class of tool. For organizations that need to understand the holistic impact of AI on their teams, balancing speed with quality, and who require a platform that delivers insights without forcing process changes, Span is designed for that purpose. It provides the ground truth needed to separate hype from reality in an increasingly AI-driven world.

The key is selecting a platform that not only meets your current needs but can evolve with your organization as development practices continue to transform. The right tool should reduce complexity rather than add to it, provide actionable insights rather than just data, and ultimately help your engineering organization achieve its full potential.

Next Steps

After evaluating and selecting a developer productivity platform, engineering leaders should consider these strategic actions to maximize their investment:

Measure Your AI Coding Impact: With AI coding assistants becoming standard tools in engineering organizations, understanding their true impact is critical. Test your code with Span’s AI Code Detector to establish a baseline for AI adoption across your teams and correlate it with productivity outcomes.

Explore Advanced AI Detection: To dive deeper into how AI-generated code is shaping your engineering output, learn about span-detect-1, the industry’s first model to identify AI-assisted versus human-written code with over 95% accuracy. This technology enables you to track adoption, monitor quality, and optimize AI tool investments.

Get Expert Guidance: Visit Span’s help center to access documentation and best practices for implementing engineering metrics programs that balance quantitative data with qualitative insights.

Connect With the Team: If you’re ready to transform how your engineering organization measures and improves productivity, reach out to Span directly to discuss your specific needs and explore how their AI-native platform can deliver immediate value for your team.

The Best Technical Content Marketing Agencies in 2025

Karl L. Hughes — Fri, 14 Nov 2025 10:29:53 +0000

Here's the problem: most content agencies have no idea how to write for developers.

I've been running Draft.dev for five years now, and I can't tell you how many times I've heard this story: a company tries to start a technical initiative, hires a "content marketing agency," and ends up with generic fluff that makes their engineering audience roll their eyes.

Technical content marketing is different. You need writers who actually understand the technology they're writing about. You need agencies that know developers don't respond to the same marketing tactics that work on other audiences. And you need teams that can produce content without getting the technical details embarrassingly wrong.

So I put together this roundup of agencies that actually get it. I've included what they're good at, what they charge (when they're willing to tell you), and real examples of their work so you can figure out which one might be worth talking to.

Why Technical Content Agencies Are Different

Most content shops can't handle technical content. They're great at writing about marketing or HR or ecommerce, but put them in front of a blog post about Kubernetes or database architecture and they're lost.

Technical content agencies specialize in the hard stuff: developer tools, SaaS platforms, cloud infrastructure, and other B2B products that require actual engineering knowledge to write about. The good ones hire writers with engineering backgrounds who won't butcher the technical concepts.

Here's who does what best:

Full-Cycle Developer Content Marketing: Draft.dev (300+ subject matter experts)
General-Purpose Marketing: NinjaPromo (omnichannel marketing subscriptions)
AI-Powered Content: RevenueZen (interview-led content generation)
Web3/Crypto: Coinbound (serves 30% of top 100 crypto companies)
Budget-Friendly: LYFE Marketing (social media management)

How to Pick a Technical Content Agency

Look, choosing an agency isn't rocket science, but there are a few things you should check before you sign anything.

First, make sure they actually have technical expertise. Ask to see case studies from companies in your space. Check if their writers have real engineering backgrounds or if they're just marketing people who learned to use technical jargon.

Second, understand what you're actually getting. Most agencies now offer way more than just blog posts. You might get video tutorials, social media content, executive ghostwriting, or AI search optimization. Figure out what you need before you start shopping around.

Third, understand the pricing. Budget anywhere from a few hundred bucks for occasional content to $20,000+ per month if you're going all-in on a full content engine.

The Best Technical Content Marketing Agencies

1. Draft.dev: Best for Full-Cycle Developer Content Marketing

Founded: 2020
Based in: Chicago, Illinois
What makes us different: In-house engineers who write, review, and strategize

Alright, I'm biased here since this is my company, but I'll tell you what we actually do.

We build content engines for developer tools companies. That means blog posts, tutorials, comparison pages, landing pages, onboarding docs, technical guides, thought leadership, lead magnets, and whatever else you need to reach developers. We adapt the format and tone based on where your readers are in the funnel and what they're trying to accomplish.

We have 300+ vetted software engineers and technical journalists who actually know what they're talking about. When we write about React or Kubernetes or database optimization, we're not guessing. Our writers have built production systems with these technologies.

We just made the 2025 Inc. Regionals list of fastest-growing companies in the Midwest. You can check out our free resources to see how we think about developer marketing.

What We Do

Content-driven lead generation
SEO strategy and topic clusters
LLM and generative engine optimization
Technical ebooks
Social media content
Written and video tutorials
Paid newsletter promotion

What We Charge

Retainers start at $7,000 per month. Most clients start with a three-month pilot and then move to an ongoing retainer.

You can browse hundreds of technical content examples we've done on our website. Book a call to learn more or subscribe to our newsletter to stay in touch.

Results We've Gotten

2. Dev Spotlight: Best for Low-Volume Thought Leadership

Founded: 2018
Based in: Indianapolis, IN
What makes them different: Built for enterprise thought leadership

Dev Spotlight goes after bigger companies that need high-quality thought leadership content but don't need a ton of volume. They've worked with names you'd recognize like Cisco, Twilio, and Circle.

What I like about them is they're not trying to scale by using AI or cheap offshore writers. They work with a small group of actual subject matter experts. They also promise you won't get stuck in revision hell, which is refreshing.

The downside is they don't publish pricing, so you'll have to reach out to figure out if they're in your budget.

What They Do

Whitepapers
Technical blogs
Tutorials
Landing pages
Case studies
Customer stories

What They Charge

Not published. You'll have to ask them.

Their Work

They don't publish case studies, but they do show samples:

3. EveryDeveloper: Best for Developer Experience

Based in: Portland, OR
What makes them different: Run by someone who actually built developer programs

Adam Duvander runs EveryDeveloper. He used to do developer experience at Zapier and Sendgrid, so he knows what he's talking about when it comes to making developers happy.

Adam's big thing is developer experience, which is basically the art of not pissing off your technical users. He'll audit your site and give you a DX Index score, then tell you how to fix the problems. He also wrote a book called Developer Marketing Does Not Exist that covers his 13 Elements of Developer Experience.

If you're struggling to figure out why developers aren't adopting your product, Adam's probably worth talking to.

What They Do

Content strategy and production
Human writers and editors
Developer experience consulting
Documentation

What They Charge

Not published. Grab time on their calendar if you want a quote.

Their Results

Stoplight got 30x more traffic with their help

4. 310 Creative: Best for Account-Based Marketing

Founded: 2003
Based in: Santa Monica, CA
What makes them different: They assign dedicated strategists

310 Creative has been around for over 20 years, which is ancient by content marketing standards. Their specialty is account-based marketing, which means they assign you a dedicated strategist who helps build a custom lead generation plan.

They do both inbound (SEO, content) and outbound (paid ads, social media outreach, direct messaging). They work with industries beyond tech, but they have a solid list of technical clients and good reviews.

Pricing is transparent, which I appreciate. They start at $4,000/month and go up to $28,000/month for enterprise ABM.

What They Do

Inbound marketing
SEO
Paid media
Conversion optimization
Account-based marketing
Outbound lead generation
Website development
Sales enablement

What They Charge

$4,000 to $28,000 per month depending on the plan. Check their pricing page for details.

Their Work

5. Hoopy: Best for DevRel Strategy

Founded: 2014
Based in: London, England
What makes them different: Strategy sessions with DevRel experts

Matthew Revell runs Hoopy. He used to do developer advocacy at Couchbase and Basho, and he's the guy behind DevRelCon, which has become the go-to conference series for developer relations folks.

Besides the usual content stuff (blogs, whitepapers, case studies), Hoopy offers DevRel strategy sessions. This is useful if you don't want to spend months figuring out your strategy from scratch. They also do research to help you understand what your audience actually thinks about your product.

What They Do

Audits
Training
Research
Audio and video production
Technical content
DevRel strategy

What They Charge

Not published. Contact them for pricing.

Their Work

No public case studies. You'll have to talk to them to learn more.

6. Wizard on Demand: Best for Deep Tech

Founded: 2018
Based in: Tallinn, Harjumaa
What makes them different: You work directly with the founder

Oleksii Klochai built Wizard on Demand for heavily technical companies. According to their site, they can cut your content marketing time by 80% and improve results by 8x. I don't know how they measure that, but those are bold claims.

They're a small team that does SEO content, paid ads, and general brand building. They also offer writing coaching if you want to get better at creating content yourself.

What They Do

Technical content marketing
Illustration and design
Information architecture consulting
SEO for technical companies
Paid media
Writing coaching for technical leaders

What They Charge

Not published. Book a meeting to get a quote.

Their Results

800% organic traffic growth and thousands of GitHub stars

7. LYFE Marketing: Best for Social Media

Founded: 2011
Based in: Atlanta, GA
What makes them different: Focus on social media management

LYFE Marketing does social media for B2B and ecommerce brands. If you need someone to manage your presence on Facebook, Instagram, Twitter, LinkedIn, or Pinterest, they can handle it.

Their thing is building a consistent presence without you having to put out fires all day. They do targeting, analytics, and ad optimization so you don't have to think about it.

This is a good option if you need to polish your brand on social media but your team is too small to handle it internally. Their pricing works for companies of all sizes, so you don't need to wait until you're huge to afford them.

What They Do

Social media advertising and management
Short video management and ads
Search engine advertising
Email marketing
Display advertising
Google advertising

What They Charge

Between $600 and $1,000 per month on average for social media management. Other services vary. Contact them for specifics.

Their Work

8. Catchy: Best for Full-Cycle Dev Marketing

Founded: 2010
Based in: Seattle, WA
What makes them different: End-to-end services

Catchy is a full-service shop that builds technical marketing programs for enterprise clients in the US and Europe. They do everything from writing and video to social media and demand generation.

Just know that they're not a content-only agency. They're more of a one-stop shop for all your technical marketing needs. That can be good if you want everything handled by one team, but it might be overkill if you just need blog posts.

What They Do

Go-to-market strategy
Demand generation
Content and creative
Developer experience
ROI tracking

What They Charge

Not published. Contact them for a quote.

Their Work

9. ércule: Best for Boutique Services

Founded: 2017
Based in: Portland, OR
What makes them different: They built an app to track content performance

ércule focuses on organic growth for business-to-developer companies. They do content strategy, SEO, analytics, and technical writing.

What's interesting is they also built an app that helps you track content performance. You connect your Google Analytics and Search Console, and their app reformats everything to help you spot opportunities. You can also chat with their team about what to do next.

The team includes ex-operators from GitHub, MongoDB, AWS, and Atlassian, so they know what they're doing. Just be aware they stay intentionally small, so they don't take on many clients at once.

What They Do

Analytics and automation
Content strategy
Content CRO
LLM optimization
Product marketing
Technical SEO and writing

What They Charge

Agency services: Not published, contact them.

Their app:

Free: Basic analytics, one library up to 25K pages, 20 topic searches/month
Pro: $59/month for unlimited libraries and searches

Their Work

No case studies published. Talk to sales for more info.

10. Siege Media: Best for Generative Engine Optimization

Founded: 2012
Based in: Austin, TX
What makes them different: They focus on AI search results

Siege Media specializes in GEO, which stands for generative engine optimization. The goal is getting your brand featured in ChatGPT, Claude, and other AI tools that people use for search now.

But they do more than just GEO. They offer product SEO, localization, PR, link building, and other organic growth services. They've been on the Inc. 5000 list six years running, so they're clearly doing something right.

What They Do

Content marketing and strategy
Product SEO
Product GEO
Content localization
Link building
Digital PR
Web and graphic design

What They Charge

Not published, but Clutch says average projects run $50K to $200K. Contact them to find out.

Their Results

11. HigherUp Digital: Best for Website Optimization

Founded: 2016
Based in: München, Bavaria (Germany)
What makes them different: Three-stage process for results

HigherUp Digital does B2B tech marketing in three stages: consulting, website optimization, and organic marketing. Everything is customized based on your company size, traffic, product, and goals.

No matter what package you choose, you'll get strategy creation, competitor analysis, paid advertising consults, website setup, and sales optimization.

This is a good fit if you're a European brand looking to expand locally or if you're launching a startup and need help with early branding and positioning. They offer a free strategy session, so there's no pressure to commit upfront.

What They Do

Website optimization
Strategy and consulting
Organic marketing
LinkedIn marketing

What They Charge

Not published. Contact them for pricing.

Their Work

12. Campfire Labs: Best for Thought Leadership

Founded: 2018
Based in: Boulder, CO
What makes them different: Executive ghostwriting

Campfire Labs helps B2B brands build authority through thought leadership and long-form content. They create stories that actually resonate with technical buyers and executives instead of the generic stuff most companies publish.

If you're trying to get your C-suite published or launch reports that position you as a category leader, they can help. For example, they helped Bonusly turn executive ghostwriting into a competitive advantage that drove deals and traffic.

What They Do

Content strategy
Design
Social content
Case studies
Thought leadership
Reports
Newsletters
Short-form video

What They Charge

Not published. Contact them for a quote.

Their Work

13. ReVerb: Best for ICO and STO Marketing

Founded: 2018
Based in: Rochester, Minnesota
What makes them different: Crypto launch expertise

ReVerb is a marketing agency for blockchain and Web3 startups. Their main focus is helping launch ICOs and STOs with technical writing, SEO, and investor marketing.

They've been in crypto for almost a decade, so they understand compliance and what actually works in this space. They also maintain a list of trusted partners for services they don't offer themselves.

What They Do

ICO and STO marketing
PR and distribution
Social media marketing
AI copy editing
SEO and link building
PPC management
Branding and reviews

What They Charge

Not published. Contact them for pricing.

Their Work

14. Coinbound: Best for Web3

Founded: 2018
Based in: New York, NY
What makes them different: They represent 30% of top 100 crypto companies

Coinbound specializes in helping Web3 companies go viral. They've worked with 800+ clients and currently represent 30% of the top 100 market cap crypto companies.

They offer crypto-specific services that are hard to find elsewhere, like access to crypto influencers and tokenomics experts. They also provide advisory services and fractional CMOs if you need strategic help.

What They Do

Exchange listing services
Tokenomics
Advisory and consulting
Crypto influencer marketing
Fractional CMOs
Community management
Social media
Branding and lead gen
PR
PPC and paid ads

What They Charge

They have an online calculator that gives you a custom quote in under 60 seconds.

Their Work

15. Responsify: Best for Brand Identity

Founded: 2013
Based in: Brooklyn, NY
What makes them different: HealthTech, CleanTech, and EdTech focus

Responsify helps B2B companies define and scale their brand identity. They combine inbound marketing, UX design, and visual storytelling to create (or fix) your brand.

Their content strategy starts with alignment, then moves to branding, responsive design, and SEO writing. The goal is making sure every touchpoint maintains your voice and positioning.

While they say they target "B2B businesses," most of their clients are in technical or SaaS spaces. Check out their case studies to see the kinds of companies they work with.

What They Do

Brand identity design
UX design
Business and customer alignment
Responsive email design
Responsive website design
Content writing and inbound marketing

What They Charge

Plans are listed but pricing isn't. Contact them for specifics.

Their Work

16. Growth Plays: Best for GTM Strategies

Founded: 2017
Based in: Los Angeles, California
What makes them different: AI-driven go-to-market

Growth Plays is a B2B agency that focuses on go-to-market strategies, including getting your brand listed in LLMs.

This is a good fit if you need a more AI-driven approach to launching products. They're not specifically for IT or SaaS, but they can help you build unified go-to-market strategies with AI-powered content workflows.

What They Do

Content strategy
Content creation
Attribution
Analytics

What They Charge

Not published. Schedule a meeting for a quote.

Their Work

No published case studies. Book a consultation to learn more.

17. Edify Content: Best for Landing Pages

Founded: 2020
Based in: Mesa, Arizona
What makes them different: Lead flow and list management

Edify Content focuses on attracting executive leads. They write SEO content, case studies, and landing pages designed to reach high-level technical decision makers.

You can also use them for lead flow and list management, though you might need to upgrade your plan. They'll set up email sequences and run LinkedIn or Google ads to build a full inbound and outbound strategy.

What They Do

SEO blogging
Case studies
Thought leadership
Landing pages
Running ads
Email sequences
Lead flow and list management

What They Charge

They use a credit system. The Starter package is $6,500/month with 16 credits:

Short blog posts: 2-3 credits
Long blog posts: 3-6 credits
Social posts (5): 2 credits
Email sequences: 4-8 credits
Landing pages: 4 credits

Performance marketing for HubSpot users starts at $12,000/month and includes ads, one-pagers, landing pages, lead flow, email campaigns, and social media.

Their Work

18. Infrasity: Best for B2B SaaS Startups

Founded: 2023 Based in: Delhi, New Delhi What makes them different: Built for early-stage startups

Infrasity does tech marketing for DevTools and B2B SaaS startups. They create, audit, and optimize SEO-friendly technical content.

Beyond blogs, they'll write use case libraries, onboarding docs, and SDK examples. If you want video, they'll make technical walkthroughs created by engineers for engineers.

What They Do

Video production
Technical writing
Landing pages
Performance tracking
Reddit marketing
Webflow for DevTool teams
Use case libraries, docs, SDK examples

What They Charge

Two plans:

Starter: Four guides/month, one SDK guide, SEO ideation, persona mapping, founder POV support, 7-10 day turnaround, up to 2 revisions
Scale: 6-8 pieces/month, two videos/month, landing pages, dedicated strategist, performance tracking, more content types

No public pricing. Start with the Starter Plan and get a 30-day proof of concept.

Their Work

Finding the Right Agency for You

Look, there's no universal "best" agency. It depends on what you need, who your audience is, and what you can afford.

Some of these agencies are great if you're an early-stage startup that needs to get content going quickly. Others are better if you're an enterprise company that needs thought leadership and strategic positioning. A few specialize in crypto or Web3, which most general agencies can't handle.

The important thing is finding an agency that actually understands your technical audience and can produce content that doesn't make them cringe. Use this list as a starting point, then reach out to a few that seem like good fits.

If you want to learn more about technical content marketing, check out these other guides:

Becoming a Senior Software Engineer

Karl L. Hughes — Tue, 09 Nov 2021 18:52:55 +0000

I used to speak regularly at many of the Chicago-area coding bootcamps and one of the common questions that students posed to me was, “How can I become a ‘senior software engineer’?”

I’ve seen versions of this question countless times on forums and Reddit threads as well, and I suspect it’s because many readers think their careers will just get easier if they have had “senior engineer” in their title.

On the other hand, companies give out this title somewhat arbitrarily.

A few years ago, I caught up with a former student who had just graduated from a bootcamp 3 years ago and had just received his first “senior software engineer” position. While I’m sure he was a standout employee, three years seems like an extremely short road to a title like that.

The truth is that there’s no accepted definition or benchmark that universally makes you a senior engineer-it might take you 3 years at some companies and 15 at others-but I do have some thoughts on this question.

In this piece, I’ll explore the four paths I’ve seen most engineers take to become senior engineers. Along the way, I’ll share some of the skills and benchmarks you might need to hit to get there yourself.

Path 1: Job-Hopping

By far, the most common way engineers get a senior engineer title the fastest is by job-hopping. Whether you do this by perfecting the art of leetcode or networking your way in, the sad truth of our industry is that by jumping ship every two to three years, you will maximize your salary and job titles the quickest.

Early in your career, this hopping around is also good for perspective. You’ll get to see a lot of different code bases, management styles, and team compositions while moving up the ladder every couple of years. Some recruiters (mostly the ones with your employers’ interest in mind) will tell you to be careful that you don’t develop a reputation, but in the first 5-6 years of your career, these short stints are normal.

With some experience and a variety of cultures under your belt, you can start to slow these hops down at some point. I tend to see the most senior engineering leaders staying for 5-10 years, which gives them enough time to run several big projects, get a promotion or two, and decide if they want to stay put or move on again.

Path 2: Grind it Out

Job-hopping isn’t for everyone and truthfully, if you find a really great boss and fair employer, you don’t need to move just because you’ve been there for a couple years. Many companies have career ladders that will give you a direct path to become a senior engineer without needing to look outside.

Unfortunately, companies tend to take advantage of long-time employees who don’t push for promotions, so you might get stuck in a situation where you’re doing bigger jobs than your title (or paycheck) would imply. If this happens to you, talk to your boss. Figure out what the roadmap is like to get you to your next role and if the company really wants to keep you, they’ll make a path clear.

There are plenty of examples of engineers who spend 5-10 years in a single company to earn a senior engineer title. That said, this path is usually a bit slower.

Path 3: Startups or Self-Employment

I’ve met many senior engineers who gave themselves a promotion by being self-employed first. Whether as a consultant, agency owner, early employee, or startup founder, you can become a senior engineer by taking your own journey into entrepreneurship.

I’ll admit, this isn’t extremely common, but in the entrepreneurial circles I run with, close to half my friends have joined or co-founded a startup at some point in their career, so I know this path exists.

Joining a startup can be a great boost to your engineering career, but you also have to consider the downsides. It’s not likely to make you wealthy quickly and the broad experience you get might not transfer to the narrow job specs that large employers want. Still, I found being a startup engineer a great way to quickly progress and many of my coworkers did too.

Path 4: Education

A graduate degree in computer science, computer engineering, or something similar could help get you closer to a senior engineering position, but it comes at a cost.

This seems like the least common path these days, likely because of the cost of college (both in raw numbers and opportunity cost) and the speed at which the industry moves. Graduate computer science degrees might prepare you to be the best at a very narrow part of the field, but if that niche falls out of favor, you might find yourself in an awkward position career-wise.

A coding bootcamp, on the other hand, will not help you get closer to a senior software engineering role. Coding bootcamps are now seen as a sign of a junior engineer, so if you’re self-taught and looking to level up, skip the bootcamp. It’s not going to make your resume look any better.

The Skills You Need to Become a Senior Engineer

Regardless of the path you take, there are some skills I’ve found all senior software engineers possess. It’s hard to say where the correlation/causation line is, but I suspect that most companies look for some degree of all these things when considering senior engineering promotions.

1. Communication

As a senior engineer, you’ll be expected to communicate more with early-career engineers, managers, and stakeholders than you did in previous roles. Because you’ll have more knowledge about the system and technology than many of your peers, you’ll be able to speak to the important considerations that decision-makers need to weigh.

Likely, this will require some combination of writing and speaking skills.

2. Multiple Programming Languages/Frameworks

I don’t know if senior software engineers tend to know more languages or if this is really a requisite skill, but I do think that knowing multiple programming languages gives you a broader base of experience and a more dynamic skillset. I’ve learned a lot by trying new languages and taking the patterns they use back to my codebase.

The good news is that learning new programming languages gets easier after your first two. I found that after learning PHP and JavaScript, Python and Ruby were relatively easy to understand.

3. Debugging Skills

Senior engineers tend to be the go-to debuggers.

While they can be important for building new features, they’re also usually the developers with the best debugging skills and most complete understanding of the entire system. This allows senior engineers to add value by helping other engineers get “unstuck.”

If you want to get good at debugging, read more code, learn to use observability tools, and don’t shy away from fixing bugs. This is an essential skill for senior engineers to have.

4. Time Management

Most people are terrible at long-term estimates, but senior engineers tend to at least be better at understanding their short-term capacity. They also tend to expect the unexpected better than early-career engineers.

I’ve met some senior engineers who weren’t great with time management, but it often held them back at a certain point. Because they’re senior, they have more visibility and are a larger line item in the team’s budget. This means more eyes watching their performance and productivity.

5. Understanding Tradeoffs

A lot of engineers early in their careers are too dogmatic. They believe things like:

“microservices are always a good choice”
“100% test coverage is essential”
“MongoDB scales better than PostgreSQL”

A senior engineer will almost always understand that every tech decision is about tradeoffs. There are very few answers that are always right, but senior engineers will know when to pick one path over another.

Learn to make both sides of important arguments and pay attention to the business needs instead of just the technical needs of each project.

Create Your Own Path

Regardless of your background, the paths I’ve seen, or the skills above, there are a lot of ways to earn a senior software engineer title. Take your own path, but find mentors, read books, and be proactive in your career. No matter how great your boss is, it’s ultimately your responsibility to keep your career moving forward.

Finally, let me know if you have questions. I’m always happy to share my experience if it can help.

API Development: The Complete Guide for Building APIs Without Code

Karl L. Hughes — Wed, 13 Oct 2021 16:00:47 +0000

The term “API” gets thrown around a lot these days, but what does it mean? What can you use an API for? Do you have to have a developer on your team to build or use an API? In this guide, we’ll explore all those questions and more, including a spotlight on the tools you can use as a non-technical founder to build your own APIs.

You don’t have to understand what an API is at this point, but if you do, feel free to skip the first section and move right into “Why Build an API?”. If you already know why you need one, then skip down to “Things to Consider When Building an API”, and if you are seasoned at building APIs but just want to know how you can build them without a developer, jump all the way down to “Tools for Building APIs Without Code”.

What is an API?

API stands for “Application Programming Interface.” Before I lose you with a bunch of technical jargon, let me put it in simple terms: an API is a way for computer programs to talk to each other.

APIs are used in almost all software, websites, mobile apps, or computer games. Some companies even make money using only their APIs, but before I get to that, let’s take a look at an example of an API you’re probably familiar with:

Ever seen a screen like this? This is a Facebook login button, and it uses Facebook’s API to allow users to verify their identity. It essentially lets you skip entering your username and password by using your Facebook account as proof that you are who you say you are. Developers who use Facebook’s API can save themselves time by not having to build their own username and password login system, instead piggybacking off of Facebook’s.

Another way that APIs can be used is to show data stored in another platform on your website. Have you ever seen a comment form on a site that looks like this?

When comments are powered by Disqus it means that the website uses the Disqus API to store their comments so they don’t have to manage them, remove spam, or write lots of code themselves. APIs can save developers a lot of time.

Here’s another great example of using an API to get data from a third-party source:

FinanceBoards uses stock market data provided by several different sources to create charts, graphs, reports, and more for investors. If you want to build any kind of stock market tracking application, you’ll need to get data like this, and stock data APIs make it relatively easy to do so.

There’s almost no end to the kinds of things you can build using APIs, and there are hundreds of free APIs you can use in your projects check out this list on Github, but that’s a topic for another time. For the remainder of this guide, we’ll focus on building APIs.

Sponsor

Want Great Content Like This for Your Site?

At Draft.dev, we create technical content for startups looking to reach software engineers. Stop begging your engineers to write blog posts and build a high-quality, reliable content engine today.

Learn More →

Why Build an API?

APIs are very powerful because they allow developers to take someone else’s work and build their own app or product from it, but why do API creators do it? It may seem that giving away your company’s data or features in an API could help your competitors, but when done right, an API can allow your company to grow into new areas that you never thought possible.

Let’s take a look at some companies that have used their APIs to grow and eventually dominate their fields.

Quora: Using an API for Internal Use Only

First of all, APIs do not have to be publicly available at all. In fact, most companies that have an API only use them internally to allow different parts of their website to talk to each other. Quora is a great example of this, as they have an API, but do not offer external developers a way to gain access to it. Instead, they use this API to keep the data in their mobile and web apps in sync.

The advantage to an internal API is that you can use the same database, business rules, and shared code behind the scenes to power your mobile app, desktop app, and website without having to worry about competitors stealing your content or developers misusing your data. So even if you never plan to give your data to partners, you may want to consider building an API simply to allow developers to build different apps with the same data. APIs are a great way to do more work with fewer developers.

Twitter: Allowing Users to Build their Ecosystem

Twitter started out with a huge focus on their API. Developers could get almost any data from Twitter they wanted - trends, hashtags, user stats - and they built some really cool stuff with it. This massive amount of open data and the tools people built actually attracted more users to Twitter. Companies could easily hook into the Twitter API to let users share their content on Twitter without leaving their site, and Twitter in turn got even more content on the platform.

Twitter might have been able to build some of these applications on their own, but there’s no way they would have been able to do everything that API users have imagined. Eventually - once Twitter dominated the microblogging universe - they tightened up their API and made partners pay for specific kinds of access. While this made early adopters mad, Twitter was able to profit from the growth of their API without sacrificing the long-term profits they now get out of it.

Diigo: An Extra Incentive for Paid Users

Diigo is a bookmarking and annotation tool with a generous free tier, convenient Chrome extension, and mobile sharing apps. Because some users wanted to use Diigo for more advanced purposes and build their own applications using the bookmarks they saved in Diigo, Diigo decided to offer a public API, but with a catch. It’s only available to paid users.

While providing the API probably isn’t much more work than servicing their UI (in fact, it might be less work as websites are notoriously hard to get right), Diigo decided that the users who wanted API access were most likely willing to pay a few bucks per month to make their lives easier using the API. It certainly hooked me in and took the product from cool to a critical part of my weekly workflow.

If your business has successfully found a tech-savvy audience that is begging for API access, you might want to consider offering one especially if you can profit from it.

Mailchimp: Allowing Integrations that Encourage Greater Usage

Mailchimp is one of the most popular email marketing tools out there, and it’s my personal favorite. It’s really easy to use, they have a generous free tier for small mailing lists, and they seem to always be the first when offering new features that are great for email senders. They also have a well-documented API that encourages even more interesting use cases.

Without their API, you can create a campaign from a template, add users to a list manually, and look at standard reports. But, using the Mailchimp API, you can build custom templates from your own website’s data, import thousands of existing users from a database, or showcase your raw email campaign data in novel ways. There’s no limit to what you can do, but all these new use cases also mean more revenue for Mailchimp as you still have to pay them to send your emails through their service. If you’re building a software-as-a-service platform that charges based on usage, an API could be a great way to increase engagement.

Aylien: API as a Service

While many APIs are a bonus or supplemental feature, some companies are built as API-first services. Aylien is a text analysis and natural language processing service that doesn’t offer a user interface at all - they just sell access to their API.

This means that developers hoping to analyze or categorize data can simply send their text to Aylien, then listen for a response with all the analysis they need. There’s no custom code involved at all, and using Aylien with existing data should take no more than a few minutes. They charge customers for this time savings though - once you go over their free tier, there’s a fee for using it.

Aylien might someday offer a user interface, but by starting out as an API-first company, they’ve aligned themselves with developers and put the focus on their technical tooling rather than UI.

Does Every Business Need an API?

“Every company in the world already has valuable data and functionality housed within its systems. Capitalizing on this value, however, means liberating it from silos and making it interoperable and reusable in different contexts—including by combining it with valuable assets from partners and other third parties.” - Apigee State of the API Economy, 2021

Many businesses have had great success building APIs that customers or other third parties can use, but you do not have to have an API, even if you are building a software-based business. In fact, the complexity of offering an API in addition to a user interface may be too much for a small startup, but it’s still good to understand when and why an API is appropriate.

Here is a list of reasons you may or may not want to build an API. While not exhaustive, this should give you a starting point when deciding whether or not an API is right for your use case.

You Should Probably Build an API If:

You want to build a mobile app or desktop app someday
You want to use modern front-end frameworks like React or Angular
You have a data-heavy website that you need to run quickly and load data without a complete refresh
You want to access the same data in many different places or ways (eg: an internal dashboard and a customer-facing web app)
You want to allow customers or partners limited or complete access to your data
You want to upsell your customers on direct API access

You Should Probably Not Build an API If:

You just need a landing page or blog as a website
Your application is temporary and not intended to grow or change much
You never intend on expanding to other platforms (eg: mobile, desktop)
You don’t understand the technical implications of building one

One thing that doesn’t have to stand in your way of building an API is not having (or being) an experienced software developer. In fact, you might be able to build a serviceable API without any custom development work, but you should understand some of the implications of giving users API access to your data.

Things to Consider When Building an API

When you build a website with sensitive or proprietary data, you probably want users to log in before they can access it. The same holds true for APIs - you shouldn’t make yours open to the public unless you want anyone in the world to have access. Even if you want the data to be easy to get, you may want to issue API keys just so you can keep track of who’s using it and potentially lock out anyone who abuses your API. Security is one consideration, but there are many other things you should think about when building an API:

Authentication

Who do you want to give access to your API? Paying customers? Internal employees? Anyone on the internet? If you want to institute any limits on how or how much your API is used, you’ll need some form of authentication. Common options include Basic Auth, API Keys, OAuth tokens, and JSON Web Tokens. I won’t get into the difference here, but there’s a great article by Zapier explaining the difference here.

Documentation

Developers who want to use your API will need some way to know how they can use it. API Documentation should describe the requests that are allowed, the format and type of data inputs allowed, and the responses returned by the API. These documents can follow certain standard formats (like the Swagger specification), or they can be different between every API. We’ll talk more about requests and responses in the next section of this guide.

Role and Route-Based Permissions

Sometimes you will need your authentication rules to be quite complicated. For example, maybe internal developers can access certain parts of your API that public users or customers cannot. Developers can build in role or route-based permissions systems that prevent unauthorized use in specific parts of your API.

Rate Limiting

When you offer access to your API to the public, it’s usually a good idea to prevent people from using it too much or too quickly. Rate limiting can prevent users from abusing your API, scraping all your data, or simply crashing your app because they’re making so many requests.

Logging/Analytics

When your API returns an error to a user, you might want to know about it. Logging can be added to capture every request and response or just the ones that failed. Logging or analytics can also help you track how much your API is being used, especially when you’re dealing with lots of third-party users.

Side Effects

What if you want to trigger alerts, link multiple API requests together, or kick off background tasks with your API? These events are referred to as “side effects” meaning that they might not be contained in the primary request and response, but are still important actions when designing your API. Usually, this level of customization has to be custom-coded, but there are ways to manage side effects without writing code.

Scalability

“Scalability” is a term that developers use to refer to the ability of your API to grow or shrink depending on the needs of your team or customers. For example, a scalable API can handle 100 users today and 10,000 users tomorrow without throwing lots of errors. Ideally, a good, scalable API will cost less when it’s not in use, but that level of scalability is tough to reach without a developer.

Speed

500 milliseconds (1/2 a second) may not sound like much time, but for computers, this is an eternity. While there’s no single answer to the question, “How fast should your API be?” many successful APIs respond within 100 milliseconds. This can depend greatly on who your users are and what they’re using your API for. Real-time stock market price APIs need to be much faster than most consumer web applications.

How an API Works

Now that you know what an API is and why it might be a good fit for your business and some technical considerations, let’s make it a little more tangible.

APIs are a way for computers to share data or functionality, but computers need some kind of interface to talk to each other. While there are many options out there, we’ll focus on HTTP APIs (also known as Web APIs) as they are the most common option in web and mobile app development.

The Building Blocks of an API

First, an API needs a data source. In most cases, this will be a database like MySQL, MongoDB, or Redis (don’t worry if you don’t know what those are, they’re basically just ways that programmers store data), but it could also be something simpler like a text file or spreadsheet. The API’s data source can usually be updated through the API itself, but it might be updated independently if you want your API to be “read-only”.

Next, an API needs a format for making requests. When a user wants to use an API, they make a “request”. This request usually includes a verb (eg: “Get”, “Post”, “Put”, or “Delete”), a path (this looks like a URL), and a payload (eg: form or JSON data). Good APIs offer rules for making these requests in their documentation.

Finally, an API needs to return a response. Once the API processes the request and gets or saves data to the data source, it should return a “response”. This response usually includes a status code (eg: “404 - Not Found”, “200 - Okay”, or “500 - Server Error”) and a payload (usually text or JSON data). This response format should also be specified in the documentation of the API so that developers know what to expect when they make a successful request.

An API can optionally do many other things (see the list of considerations above), but these three things are the most fundamental for any API. To make these concepts even more concrete, let’s access a couple real APIs and see what they look like. Don’t worry, you don’t have to know how to code to follow along.

Accessing an API from Your Web Browser

HTTP APIs actually use the same method of communication that your web browser uses when it accesses websites. This means you can access some APIs by simply typing a URL into your browser.

For example, Open Food Facts has a free API for getting information about foods and ingredients. You can go to this link in your web browser to see the API response for all the data they have on “Stir Fry Rice Noodles”.

When you go to that URL, you’ll see a mess of data like this:

{"status":1,"product":{"ingredients_text_with_allergens":"RICE NOODLES (RICE, WATER), SEASONING PACKET (PEANUT, SUGAR, SALT, CORN STARCH, SPICES [CHILI, CINNAMON, PEPPER, CUMIN, CLOVE], HYDRDLYZED SOY PROTEIN, GREEN ONIONS, CITRIC ACID, PEANUT OIL, SESAME OIL, NATURAL FLAVOR).","generic_name_en_debug_tags":[],"nutrition_data_per_debug_tags":[],"additives_prev":" [ rice-noodles -> en:rice-noodles  ]  [ noodles -> en:noodles  ]  [ rice -> en:rice  ]  [ water -> en:water  ]  [ seasoning-packet -> en:seasoning-packet  ]  [ packet -> en:packet  ]  [ peanut -> en:peanut  ]  [ sugar -> en:sugar  ]  [ salt -> en:salt  ]  [ corn-starch -> en:corn-starch  ]  [ starch -> en:starch  ]  [ spices -> en:spices  ]  [ chili -> en:chili  ]  [ cinnamon -> en:cinnamon  ]  [ pepper -> en:pepper  ]  [ cumin -> en:cumin  ]  [ clove -> en:clove  ]  [ hydrdlyzed-soy-protein -> en:hydrdlyzed-soy-protein  ]  [ soy-protein -> en:soy-protein  ]  [ protein -> en:protein  ]  [ green-onions -> en:green-onions  ]  [ onions -> en:onions  ]  [ citric-acid -> en:e330  -> exists  -- ok  ]  [ peanut-oil -> en:peanut-oil  ]  [ oil -> en:oil  ]  [ sesame-oil -> en:sesame-oil  ]  [ oil -> en:oil  ]  [ natural-flavor -> en:natural-flavor  ]  [ flavor -> en:flavor  ] ","nutrition_data":"on","ingredients_from_palm_oil_n":0,"editors":["","thierrym","manu1400","andre","upcbot"],"allergens_hierarchy":[],"brands":"Thai Kitchen,Simply Asia","link":"",...}

Obviously, this is impossible for humans to make sense of, but it’s actually formatted in “JSON”, a very common and easy-to-parse format for computers. To see the data in a more readable way, you can format it using a JSON formatter.

Go to jsonformatter.org
Copy/paste all the messy-looking text from the openfoodfacts API response above into the left-hand side of the JSON formatter.
Click “Format/Beautify”

Now the data is a little easier to look at. Congratulations, you just made your first real API request!

Accessing an API from Postman

The example above was simple because the API didn’t require any authentication and we were just making a “Get” request to see all the data about a single product. If the API you’re accessing or building is more complex, you’ll likely need to use an API tool like Postman.

To set up Postman, download it for your operating system here.
We’ll be using the Holiday API, so go to holidayapi.com and sign up for a free API key.
Enter the URL https://holidayapi.com/v1/holidays into the Postman address bar
Click “Params” and enter your key, country, and year.
Click “Send” to make the API request to Holiday API.

Just like the response from Open Food Facts, the Holiday API returns a JSON data structure:

{    "status": 200,    "holidays": {        "2017-01-01": [            {                "name": "Last Day of Kwanzaa",                "date": "2017-01-01",                "observed": "2017-01-01",                "public": false            },            {                "name": "New Year's Day",                "date": "2017-01-01",                "observed": "2017-01-02",                "public": true            }        ],        ...   }}

In addition to making complex API requests easier, Postman also makes responses easier to read by formatting them. This means you don’t have to use a tool like JSON Formatter to make API data readable.

Accessing an API from Code

While using your web browser or Postman is great for testing and exploring an API, you (or your customers) will eventually want to connect to your API using code. There are many ways to do this, including:

CURL from the command line
AJAX or Fetch API in Javascript
Net::HTTP in Ruby
Unirest in Java

Pretty much every programming language or framework has an HTTP library that you can use to make API requests, but I won’t cover them in detail here as this guide is all about no-code solutions. Just know that developers who want to use your API will likely need a tool like this.

Tools for Building APIs Without Code

Now that you know what an API is, why you might need one, and how to access an API, you’re ready to get your hands dirty and actually build one. All of the solutions below (with the exception of the last two) require no code, but many of them can be enhanced or improved with some custom development work.

I find this model of starting with a no-code prototype and then enhancing it with code from a developer to be ideal as it allows you to test your API before you hire a software engineer.

Sheetsu

Description: Sheetsu might be the easiest way to get started building an API because you probably already have some data in a spreadsheet that will make up the backbone of your application. Sheetsu takes any Google Sheet and turns it into a queryable, flexible API.

Pros:

Super simple to get started. This is truly a zero-code solution
Authentication via an API key
Route-based permissions
Automatically generated docs
Input forms to allow users to add content
Can use with Zapier to trigger events in other services, send emails, etc.
Includes “instructions” you can email to developers to help them start using your API
“Handlebars” option allows you to create a frontend template from your data

Cons:

Does not allow you to enhance your API with custom code
No user roles for advanced permissions
Linking data in multiple tables isn’t really possible
Query options are somewhat limited (just a simple search by field)
Doesn’t appear to allow rate limiting
While there is a free plan, it’s extremely limited, and you’re likely going to have to move to the $49/month plan pretty quickly

Airtable

Description: I’ve started using Airtable for almost everything that I used to pack into spreadsheets. The big advantage to using Airtable for your API is that they have an excellent visual user interface and integrations with many other tools built-in. Plus, you can use Zapier to trigger custom actions when new items show up in Airtable.

Pros:

Super simple to get started, another zero-code solution
Authentication via a single API key
Permissions using sharing settings in UI
Input forms to allow users to add content
Can use Zapier to trigger events in other services, send emails, etc.
Database-style linking between records
Query by complex functions for advanced filtering and searching of records
User roles allow limited role-based permissions
Excellent automatic documentation generated for each table
API is automatic. Every Airtable you make already has API access

Cons:

Officially only allows up to 5 API requests per second, which might be fine for light use, but could be limiting as you scale up
Authenticating users requires them to have an Airtable account and generate their own API key
Not as customizable as some options

WrapAPI

Description: In theory, WrapAPI is a powerful and extremely useful tool for scraping data or making your own static website or spreadsheet into a queryable, dynamic API. In practice, it’s a bit more complicated. I have played around with WrapAPI quite a bit, and while I’m highly technical, I found that it only works correctly for some websites. Relatively simple HTML-only sites tend to work best while complex “client-side” apps tend to get lost.

Still, it’s worth trying this tool out if you already have your data on a web page (maybe an HTML table) and you want to expose it via an API as well.

Pros:

Great if the data you have already exists on the web and it’s displayed on a simple webpage
Would also be useful for monitoring web pages that don’t offer “official” APIs
API-key based authentication
Generous free tier (30k requests/month)

Cons:

Can’t save data through the API, they are read-only
No logging, or extensions, and customizability is limited
A little more difficult to get set up unless you know how HTML and CSS selectors work.

Restdb.io

Description: What I like about RestDB.io is that it starts simple, but is very powerful if you are a developer. Unfortunately, it’s not quite as easy to add things like authentication or validation as it is in some platforms, but if you have some Javascript chops, you might be able to write that on your own.

Pros:

Can create “lookup” relationships between records
Can bring your own database to customize even further
Pricing is very good and each tier scales really high
Lots of features can be added via “Codehooks”:
- Authentication
- Logging
- Emails
- Role or route-based permissions

Cons:

If you want to get beyond basic use-cases, you’ll need a developer to help
The auto-generated docs are too simplistic
Vendor lock-in is a likely problem once you scale. While you can export your data, it would be pretty arduous to rebuild lots of custom Codehooks

Bubble

Description: Bubble is probably the best web application builder I’ve seen for those who don’t code, and because it also includes an option to expose your data or workflows over an API, it’s worth noting here. You can hook into your application’s permission settings to manage access to resources or keep certain resources hidden completely. If you’re already using Bubble for your website, then using them to generate your API is an easy decision.

Pros:

Permissions and authentication managed the same way as it is in the application builder
Documentation generation with Swagger
Logging through Bubble’s admin interface
Creating data models is pretty simple and you can import CSV files with your data

Cons:

Learning Bubble is a big undertaking, and if you go with them, you’re likely all in
Not quite as customizable as building your own API with code, but it’s pretty close

Algolia

Description: For searching data, Algolia is simply magical. Most other solutions here aren’t concerned with performance because often, building an MVP doesn’t warrant it, but if you’re in need of speed and you have a lot of data, Algolia is a great solution. It can take some technical setup depending on how you want to use it, but there’s a Zapier connector in the works, and you can upload records via CSV or JSON. Even if you can’t write code, you can probably get Algolia working for you.

Pros:

Super-good at searching, setting up search rules, and speed
Slightly more difficult than editing a spreadsheet, but not much
Can be used as a replacement for Solr or Elasticsearch (if you don’t know what those are, don’t worry about it)
Logging is available
Scales up as high as you want

Cons:

Limited flexibility and customization
No documentation generation
Can get expensive at higher use levels

Strapi

Description: Strapi is an open-source content management system that lets you self-host an API on your own server in minutes. Even if you’re not an experienced developer, you can probably follow the setup instructions to get started. The biggest limitation today is that you’ll need to run and maintain a server to host your Strapi backend. But, as an open-source company, I imagine Strapi will add a hosted version that makes it even easier for non-technical users to get started with.

Pros:

Very flexible and fast
Includes a GraphQL interface, which is a better option for some use cases
Can build complex relationships between data models
Permissions and authentication rules can be set granularly
Scales up as much as your server can handle
Free (but you do pay for your server)

Cons:

Not completely “no-code” because you have to setup and run it on your own server
More complicated to set up and configure than some options

PHP CRUD API

Description: If you’re semi-technical or you can hire a developer to do some initial setup, PHP-CRUD-API might be a great option. Once you hook it up to an existing MySQL, Postgres, or SQL Server database, it automatically generates an API that is documented and highly customizable. The downside to this approach is that you’ll have to pay to host and set up the application. The upside is that it should scale with you long after your MVP.

Pros:

Much more flexible as you can view and modify the whole app’s source code
Once set up, you just have to modify your database schema to modify the API
Scales as much as the server you put it on
Automatic Swagger documentation generation
Works great if you already have an existing database

Cons:

Not really a “no-code” solution as you’ll likely have to have a developer set it up for you
While the application is free, you will have to pay for hosting it (probably $5-$25/month)
No authentication, logging, triggers, etc. included out of the box, but they can be added with some custom coding

Conclusion

Building an API without code is getting easier every year. When I first wrote this guide in 2017, the options were limited, but with the widespread growth of cloud services and low-code tools, I’ve been able to add many new options to this guide.

I intend to keep updating this guide periodically. If you have your own suggestions for building APIs without code, find me on Twitter to let me hear about them.

The Startup Tools I Can't Live Without

Karl L. Hughes — Thu, 07 Oct 2021 19:07:38 +0000

I’ve always liked trying new software tools, but the more experienced I get, the more solid my business operating system has gotten. As I refine the toolset I use for running my startup, I like to keep a running list of the tools that I use and recommend.

While I’m always open to trying new things, I don’t add tools here unless I personally use them and endorse them.

Entries are broken down into categories and include a bit about how I use them. If you’re interested in a longer explanation, email me and I’ll send you more details.

Organization

Airtable - I use Airtable as a content calendar, personal CRM, applicant tracking system, and much more. It’s essentially a spreadsheet-like interface for structured data.
Trello - Trello is my go-to project management and life organization tool. I use it for my daily and weekly to-do lists and managing team projects.
Notion - I use Notion for my side projects. It’s a bit more flexible than Trello, but (until recently) didn’t offer an API, so it’s not as powerful as Airtable.
Zapier - I automate everything I can with Zapier. I’ve also tried and liked n8n, but until they’ve built all the connectors that Zapier has, I’m still more heavily locked into Zapier.
Calendly - I never knew I needed Calendly until I started a business. It cuts down on so many back-and-forths around scheduling.
GSuite - Maybe this one is too obvious, but half my life is in the Google Suite. We use it for documentation, delivering content to clients, diagrams, team emails, and much more.
Toggl - I’ve tried several tools for time tracking, but Toggl is my favorite. The weekly reports help me see which areas of my business I’m spending time on and help me direct my priorities for the week ahead.
Diigo - I use Diigo as a bookmark organization system and a way to pipe interesting articles into my email newsletter.

Payroll and Freelancers

Pilot.co - We have contractors in 27 countries, and Pilot was the best payroll solution I could find for our use case. They’ve been very helpful about understanding international taxes and laws too.
Gusto - For full-time employees, Gusto is the best option available today. It’s affordable and lets you easily layer on other benefits.
Upwork - I’ve hired developers, writers, and designers on Upwork. While you have to wade through a lot of junk to find the few good people there, they make it really simple to hire freelancers.
Fiverr - For very short-term projects, I use Fiverr. Things like logo design, bug fixes, and presentation design are all easily outsourced to Fiverr members.

Writing

Google Docs - After trying a few methods, I found the editing and commenting features in Google Docs in addition to the Grammarly integration to make it the easiest tool for writing. If only it supported Markdown…
Jekyll - While not the most modern static site generator available, Jekyll works well. Most of the blogs I operate run on Jekyll at this point.
Grammarly - I love that Grammarly takes care of most of the little details when you’re writing. It’s saved me from a lot of comma splices over the years.
Typefully - Twitter really loves threads, so I’ve been doing more of them lately. Typefully is the best tool I’ve found for writing them.

Video

Zoom - While I’m heavily using GSuite for most of its services, I think Zoom is better for video calls. Despite a clunky calendar integration, it tends to establish a more reliable connection.
Loom - Our team at Draft.dev is remote and mostly asynchronous. Loom is a great tool for sharing quick instructions with the team or helping people get unstuck without needing to hop on a call.

Programming

Jet Brains IDE - Jet Brains’ suite is the first IDE I’ve had that cost money, and it’s the best one I’ve found overall.
DigitalOcean - Simpler than the big three (Azure, AWS, GCP), I like DigitalOcean’s philosophy of minimal hosting options. The templates they offer are a nice middle ground for getting started quickly.
Vercel - On the other end of the spectrum, I often use Vercel to host small, frontend-heavy projects. Very quick to get started with if you’re working in Node/JavaScript.
Github - Not only a code-sharing platform, Github is my go-to static site host and CI/CD platform as well.

Sales and Marketing

Carrd - Carrd is the best one-page landing page builder I’ve found. For testing a new project idea or email newsletter, Carrd is the best.
Webflow - Once you need more than a single page, Webflow is pretty solid. It’s significantly more complicated than Carrd, but more powerful as well.
Pipedrive - I don’t love it, but it’s the best CRM I’ve found for my relatively minimal needs.
Mailchimp - Mailchimp is probably the best all-purpose email management tool available. I keep most of my email lists here, but it’s pretty easy to port them to another provider if you want.
Curated - For my weekly email newsletter, I’m currently using Curated. It’s a little more complicated than I’d like, but it’s a lot better for sending “list of link” style emails than Mailchimp.
ahrefs - My go-to SEO tool, ahrefs also provides some really solid educational material on their blog and YouTube channel.

Payments

Stripe - Stripe has revolutionized the world of online payments. While it can still be messy and confusing at times, it’s an order of magnitude better than the old solutions I remember early in my career.
Moonclerk - Moonclerk adds recurring billing to Stripe for just a few dollars per month. It’s not that customizable, but it’s really simple to use.
Invoice Generator - One of Moonclerk’s missing features is proper invoicing. So, I use Invoice Generator to create and send them manually for clients who need them.

Misc

Canva - I’m definitely not a designer, so I like how simple Canva is for creating images, logos, book covers, and more.
Wohven - Wohven takes care of my t-shirts by sending me a new one every month as mine fade.

Managing Direct Reports at a Startup

Karl L. Hughes — Wed, 29 Sep 2021 15:08:43 +0000

===

I remember the first time I was put in charge of a team at a startup. I had been in leadership roles in college, but that was nothing compared to managing software engineers who were 5 to 15 years more experienced than myself.

It was scary and it stretched my comfort zone, but ultimately, learning to manage direct reports effectively was one of the most valuable skills I picked up early in my career.

What are Direct Reports?

Direct reports refer to employees that report directly to someone above them in an organization’s hierarchy. This person can be a team leader, supervisor, or manager.

In a startup, most organizational structures are simple, and might just consist of a founder with a few division heads or managers each responsible for a few direct reports.

As a startup manager or team lead, you are responsible for assigning work to direct reports, monitoring their performance, reviewing deliverables, providing feedback, and offering support whenever necessary. It’s your job to give your team direction and keep them motivated to meet deadlines and exceed expectations.

The hardest part of making the transition from team member to manager for me was changing the nature of my relationship with my peers. I was no longer on equal ground with them, but it’s not like I felt comfortable with having authority over them either.

Far too often, new startup managers struggle with this transition from peer to superior. Many have to deal with high expectations from the get-go and receive little to no formal leadership training. On top of that, management teams at startups tend to work longer hours, which can quickly lead to stress and burnout.

In this guide, I want to share some of the most common challenges I faced as a new startup manager. I’ll pass along a few tips that I hope will help you become a more effective leader to your direct reports as well.

Interested in learning more about management? Here are my favorite books for managers so you can fill up your reading list.

How to Manage Direct Reports

Effective leadership is important because it improves your team’s productivity and morale. It goes without saying that every workplace needs to invest in educating its leaders on the qualities and practices of effective leadership. However, this is rarely a reality, especially for startups with limited resources.

I’ve been managing teams for a few years now, and there are a few things I always aim to do as I hire, onboard, and adjust to my new direct reports:

1. Get to Know Your Team

Establishing open and honest communication in your team can lead to many advantages, such as an increase in productivity, job satisfaction, and teamwork.

If you’re new to the company, schedule one-on-one meetings with your direct reports. You can get to know them better and build rapport. Even if you’ve worked with your peers before, one-on-one sessions are very useful because they will reinforce your relationships with fellow team members. You can understand their expectations from you as their new leader. You can also figure out which communication styles fit your direct reports.

Ask inquisitive questions that can help you gauge employee experience. Prompt them to share what motivates them at work, what they’ve been struggling with lately, what they’ve learned recently, how they feel about the company and its direction, or how they’ve been generally doing.

Facilitating open conversations can let the team know that you care and that you’re listening. However, don’t overdo it. Avoid offering advice unless they ask you to, especially when it comes to personal problems that might be affecting their performance.

Be consistent with these one-on-one meetings. No matter how brief, you should carve out time in your schedule to talk to each direct report. This would let your team know that they are valued and appreciated.

2. Give Feedback

Giving your team constructive criticism can help them improve their overall performance and minimize errors in the future.

Aside from holding one-on-one meetings to get to know your team better, you can use these sessions to evaluate their performance and provide feedback. I like doing structured feedback sessions every quarter using a rubric to gauge each employee’s performance.

By doing regular performance evaluations, you can identify knowledge and skills gaps in your team. If, say, multiple new hires are struggling to finish projects on time, there might be a problem with the systems or expectations you have in place. You can respond quickly by providing additional resources and training to fill in those gaps.

3. Focus on Your Team’s Growth

Professional development is often overlooked, but it is a very crucial component of every successful business. As a manager, you should play an active part in your team’s professional development. Ask them: *What are your long-term goals? Do you feel like you’re making progress on your goals here? *

The more rapport you have with your team, the more likely they will be to share their goals with you. Many of the employees you talk to not be able to answer simply because they’ve yet to be asked about these things. In such cases, don’t force them to answer. Give them time to reflect. Instead, revisit the discussion in future one-on-one meetings.

Talking to your direct reports enables you to get a better understanding of their personal and professional goals. You can create a development plan around these goals and provide proper guidance. In doing so, you can nurture the future leaders of your company.

Take note that a development plan has to be customized to fit the abilities, interests, and goals of each employee. Thus, no two development plans are the same.

An effective development plan can help your team gain the knowledge and skills they’d need to propel their careers. That means you should invest in opportunities for growth. These may come in the form of special projects, one-on-one coaching, conferences, or network events. Then, you need to create opportunities within your organization where they can apply their new skills.

By focusing on your team’s growth, you can retain top talent, which would save a lot of time, energy, and money on recruitment, onboarding, and training.

The cost of losing an employee is high. One study found that replacing a highly skilled worker costs an employer about 213% of their annual salary. However, Global Industry Analyst Josh Bersin posits that the true cost of turnover ranges from tens of thousands of dollars to two times the annual salary of the worker.

4. Empower Your Team

The biggest mistake new, insecure managers make is micromanaging instead of empowering their team. Your best employees will thrive when given more autonomy.

As a leader, you must demonstrate trust to drive productivity. Allow your team to make their own decisions and take responsibility for the outcomes. This can boost the creativity, motivation, and performance levels of your team. It can also improve employee experience, which can lead to lower absence rates and turnover rates.

Autonomy in the workplace means giving your team the flexibility and options to achieve their performance goals in their own way. Instead of laying out the directions for reaching their targets, give them a supportive nudge. For instance, you can delegate projects and give your team authority over them.

Increasing autonomy doesn’t mean abandoning your team.

You shouldn’t leave them to solve problems all by themselves. You still have to provide guidance. Ask them questions that can prompt your team to devise their own solutions. It’s your job to help them define and dissect the problem so they can come up with appropriate solutions.

Apart from encouraging more autonomy, you can empower your teams by nurturing an open, judgment-free workplace, where your employees can freely share their opinions and ideas. Recognizing risks and rewarding accomplishments can empower your teams, too. In workplaces where employees feel valued and respected, motivation is usually high.

5. Use Technology When You Can

There are all kinds of tools on the market that can help you manage direct reports. In general, these tools give you access to everyone and everything you need, including your work and your apps, from a single platform. It simplifies and streamlines operations for you, allowing you to give updates, feedback, and recognition from the same tool.

Having the right tools improves your effectiveness as a manager. You can delegate tasks, run meetings, and measure performance levels more effectively with reliable tools at your disposal. You can also automate mundane and repetitive tasks, so you can focus on value-added activities.

My Management “Stack”

I have used a lot of different tools for managing my direct reports over the years. Many are right for some teams and wrong for others - for example, I no longer use Slack, but other businesses depend on it.

Take a look at these tools and use them as a jumping-off point for building your management tool stack.

Trello

As one of my go-to project management tools, Trello is simple, powerful, and relatively easy for new teams to pick up. I use a standard format with columns for:

Backlog - Projects that haven’t been fully planned. This is a good place to keep ideas.
Planning - Projects that are being fleshed out. Usually we’re still learning about the issue or coming up with possible solutions.
Ready - Cards in “Ready” are prioritized and fair game for any relevant team members to start on.
In Progress - When team members are actively working on a project, they move it to “In Progress.”
Done - After they’re done, the card is moved to “Done” where we archive old cards after a few weeks.
Recurring - Some tasks come back every month or week, so for this we use Trello’s card repeater and bring them back every week or month.

At $10 per team member, Trello provides incredible value, especially as they’ve added more integrations and automations over the years.

Airtable

I use Airtable for hiring, storing professional contacts, and much more. It’s a very versatile tool, and like Trello it integrates with most other tools via Zapier or direct API access.

Google Suite

Google Docs, Sheets, and Slides have basically caught up to Microsoft Office now, plus they’re basically free. The sharing and collaboration settings are intuitive, and they can also be integrated with many other management tools I like.

Status Hero

Status Hero is an online communication tool designed to replace lengthy meetings with concise interruption-free reports. It’s ideal for remote or hybrid setups with a distributed workforce as it increases transparency and simplifies processes.

15Five

15Five is a performance management tool that enables you to support your team’s growth through real-time feedback, recognition, weekly check-ins, and one-on-ones. Apart from its suite of products, 15Five has resources and courses to improve your effectiveness as manager.

Briskine

I just recently started using Briskine to help my team share common email templates. I’ve only recently started managing marketing and account management teams, so having a shared directory of email templates has been really helpful.

Introduction to Publii, the Static Site Generator

Karl L. Hughes — Wed, 22 Sep 2021 17:32:46 +0000

There is so much to consider when making a basic website. You have to think about how to get a domain name and where to get it. You need to work out the general costs of building and maintaining it, where you can host your content, and how much the hosting would cost, alongside actually doing the coding and getting all the assets together. You need to performance test it, make sure it is kept up-to-date, and configure a process to get code regularly deployed out. On top of all that, there are web-safety standards like configuring HTTPS instead of HTTP to ensure the connection is encrypted.

This can be confusing and overwhelming—especially if you aren’t familiar with software development or web development. Static site generators (SSG) were introduced to solve this problem: How do you easily create and maintain a website?

Publii is one such SSG. In this article, we’ll look at the general user experience, and take a high-level overview. We’ll cover some of the pros and cons and discuss who it’s best suited for.

This article is aimed at bloggers or marketers, so you won’t need any advanced developer knowledge to engage.

What Is a Static Site?

To accurately explain what SSGs actually do, you have to first understand what a static site is.

A static site is a site that will load the same way every time. It doesn’t greet you with your name or load personalized content. Nothing on the website changes unless the author specifically changes it.

SSGs are normally very non-technical, so coding experience is not essential. The interface is what’s known as a “point-and-click” experience, which means users set things up visually, rather than via code.

Due to their ease of use, their usage and prominence have increased quite significantly.

Publii

Publii’s About page describes it as a “fresh new app on the block that opens up fresh avenues for creating interesting, attractive static websites,” and briefly discusses how its two creators have “many years of accumulated academic and practical knowledge.”

Publii has been around since 2016, so it is mature with a large ecosystem around the product.

Some of its key benefits are summarized below:

It’s safe. The app is “near-impenetrable” to hackers as it works locally, so you don’t need to worry about security updates and manually managing databases to store your work.
It’s portable. Publii is just a desktop app so you can manage your website anywhere, and it allows multiple users to all collaborate on one website.
It’s easy to migrate. If you’re moving from WordPress, it has a built-in WordPress importer to transfer your posts, pages and categories.
It’s fast. The speed of Publii’s web pages is very impressive and they are designed with performance in mind.

We’ll dive into further details of some of these features later, and answer key questions to help you consider which SSG best suits your use case. We’ll cover:

Set Up

It’s really quick to get up and running with Publii. To start, simply go to Publii’s download page and download the desktop app.

There are options for MacOS, Windows and Linux depending on which operating system you use, but there are some minimum system requirements that you can find here.

My Publii Site

To actually get a feel for using Publii I made a really simple website, tweaked the UI a little, made some posts with filler text, profiled my site and deployed it out.

First Impressions

On first opening Publii I found it really intuitive. It has a really clear left-hand side (LHS) menu with all the options you may want to use (like adding authors, tagging your posts, creating new posts, or changing your UI, etc.)

I was able to quickly produce a basic site and view my changes with a Preview your changes button.

I filled out a few posts with some basic template text and looked at the different themes.

Each section was clearly laid out and had lots of sensible defaults prefilled so you don’t have to spend a long time configuring it to make full use of its features.

You are able to create multiple sites which is a great benefit, and I was surprised how much you could do completely offline.

UI

Making UI changes with Publii was seamless and easy. Your site is split out into lots of separate sections, so you just find the setting on Publii and change what you need. The Preview your changes button lets you really quickly iterate to achieve your desired design.

Creating Posts

My website was going to be a really simple blog. Publii offers three different options for generating posts: WYSIWYG editor, Block editor, or a Markdown editor. Having the three options gave me a flexible and convenient way to produce content that best suited me.

Developers tend to use Markdown, which is a way to add formatting elements to your text (like bold, italics, images, and headers).

If you aren’t familiar with Markdown, try the What You See Is What You Get (WYSIWYG) editor as it’s similar to traditional word processing with tools to control the whole flow of your content.

Speed Profile

Speed is a key concern for websites. If your website takes between one second to three seconds to load, the probability of users bouncing off your page increases by thirty-two percent; that bounce rate increases to ninety percent if a page takes more than three seconds.

So when I finished my website I used Google’s Lighthouse to profile the site’s speed.

It received a perfect score. Very impressive!

Search Engine Optimization (SEO)

SEO relates to things you can change on your website to try and optimize how discoverable you are to search engines like Google. I wanted to test Publii’s default SEO settings, so I made no changes before running a Lighthouse test:

It received a score of ninety out of a hundred, which is impressive, and I think I could have made it higher with some simple tweaks to the default settings.

Deployment

If you’re not familiar with developer technologies, the deployment process might be tricky. Everything up to this point has been very easy to do, and the deployment might be the hardest part, but it is by no means overly difficult.

You’ll have to choose which server you want to use, create any accounts you need depending on the platform, and follow the tutorial.

It took me around ten minutes, and the tutorial was really clear. I went with GitHub pages as I already have a GitHub account. The actual deployment took less than thirty seconds and then, after it was connected, whenever I previewed my changes I could simply “Sync” my current Publii changes to the server to get changes deployed out.

It’s well within the scope of a non-technical person, and I haven’t seen another SSG do this any better than Publii.

Support

An important part of creating anything is help if you ever get stuck. Publii has quite a few ways to help. Firstly, scattered throughout the relevant places are tutorials of how to do each new thing (like deploying out to servers).

If you can’t find it in the tutorial, or you can’t find the solution in their documentation, they also have a help Forum where you can ask any question you can’t find the answer to.

Security

Publii’s security is great. Many hacking attempts try to leverage code injection—this allows hackers to run malicious code on your website, but only if there is code currently running.

In static websites, you only send generated website files making the site “nigh impossible” to hack without gaining direct access to the server.

Limitations

The biggest limitation if you choose Publii is that it is a static site generator.

If you need a complex, dynamic website that lets users log in and purchase things, and on which you can change stock levels, Publii probably would not be your best choice. Publii isn’t trying to do too much and they have their use cases well laid out. This post compares Wordpress with Jekyll, another static site generator, highlighting the differences with dynamic sites.

Another potential weakness I noticed, from reading posts in the official Publii Forum, was that many users who wanted to configure their post URL’s a certain way could not because Publii doesn’t allow that. This use case won’t affect my example site, but it may be something to consider.

Conclusion

I was really impressed with Publii. It is open source, fast, and simple to use. The company has shared what’s on the roadmap for the coming years and you can learn more here, or review what has recently been added. You can quickly look at the effect of tweaking parts of your site, develop it offline, and go from idea to viewing a complete website incredibly fast. Publii listens to its users and it continues to improve with every new release.

I hope this review has been helpful.

By Kealan Parr

Technical author and member of the Unicode Consortium. Interested in reading, chess, finance, exercise & tech.

Want ideas for your next blog post?

Kickstart your content marketing efforts. Download our list of 50+ winning ideas for your company's blog today.

Download Now!

SEO Keyword Opportunities in Developer Marketing

Karl L. Hughes — Thu, 16 Sep 2021 11:51:14 +0000

We recently started supporting our clients at Draft.dev with keyword research which, given our unique position, has generated some exciting opportunities. We work with an array of clients, targeting different kinds of customers, in a hyper-defined niche: software development.

Developer marketing is unique. It moves fast, and new terms are being popularized constantly. These factors, plus our position as a content marketing agency in the space, have allowed us to rank well in Google searches—fast.

In this piece, you’ll get an overview of these opportunities. I’ll offer a tiny bit of free keyword research, but competitors in our space are moving quickly. Much of this information will be outdated in 3-6 months, so it’s critical to reassess your keyword research regularly.

Finding Good Keywords in Developer Marketing

Although the specific long-tail keyword data I use in this article will become outdated soon, the underlying strategy is evergreen. I recently broke this process down into five steps, but it all starts with finding the right keywords.

1. Find a good keyword 🔑

It's a little bit art and a little bit science. 🧪

I typically target keywords with >100 monthly searches and <20 difficulty in @ahrefs.

Let's go with "cto interview questions" pic.twitter.com/gMWjLqq9gQ

— Karl L Hughes (@karllhughes) June 29, 2021

I use ahrefs to find estimated search volume and ranking difficulty. While these metrics aren’t perfect, they’ll give you a pretty good sense of how easily you can rank for a search term in developer marketing.

The hard part about finding good keywords in developer marketing is finding terms popular enough to have significant search volume, while being new enough to escape saturation.

Let’s look at six topic areas that meet this criteria. Using these terms as a starting point will help you write better technical content aimed at developers, while also helping you rank better in search engines.

1. Kubernetes

Linux containers are not new, but Kubernetes is suddenly dominating the container and DevOps space. You’d think most of the tooling you need would’ve been built already—especially with a big corporate backer like Google. But lots of startups are creating tools for Kubernetes right now.

Given its fast, widespread adoption, it’s no surprise to see an influx of developers learning about Kubernetes. And to learn about anything, you need good content. Ahrefs currently shows five terms containing the word “Kubernetes”, with more than 1,000 monthly searches and a difficulty of 30 or less.

But it’s not all about top keywords. There are thousands of long-tail keywords we’ve investigated for various clients in order to come up with worthwhile content topics, such as performance testing, virtualization, and scalability.

The key to writing good Kubernetes content is technical expertise. If you search for related terms, you’ll find lots of cookie-cutter, jargon-filled fluff pieces. This kind of content doesn’t really fly in developer marketing; to compete you’ll need content written by experts—for experts.

2. Python

Python recently became the most searched for language in Google. So as you can imagine, there’s tons of demand for good content to capture developers’ attention.

Useful search terms for companies to reach Python developers include:

python square root, 9,400+ monthly searches
python random number, 7,300+ monthly searches
python read csv, 5,400+ monthly searches
python command line arguments, 5,000+ monthly searches

In a real keyword research project, you’d filter terms by your target audience and product use case. But with thousands of keywords having a difficulty score less than 30, you’re sure to find a few good options.

3. GraphQL

“I consider GraphQL to be the most exciting thing to happen to APIs…I’d go so far as to say that GraphQL is the new REST.” - Nate Murray, Founder at newline

GraphQL is hot right now. This popularity comes in spite of its age, given some very mature projects use it as a query language and API interface. Search volume for GraphQL isn’t as high as other topics on this list. But using it alongside other popular frameworks and programming languages presents a very interesting opportunity.

GraphQL is a “glue” technology (it’s typically used in conjunction with other developer tools), so the tutorials and content you can write on it are limitless. The only question is whether GraphQL’s popularity will fade away, or eclipse REST as the go-to API query language.

4. Go

Go has been around for over a decade now, with a small yet loyal following. While only used by around 9% of programmers, Stack Overflow ranked Go as the third “most wanted” language. It’s no surprise that our list of Best Go Blogs is one of our most popular Draft.dev blog posts.

The demand for Go has driven lots of developers to learn it, with many looking for jobs that use the langage. While Python or JavaScript are more popular in production workloads, increased curiosity around Go has led to a lot of search traffic considering its market share. Fundamental search terms like “golang ternary,” “golang for loop,” and “golang substring” indicate a strong market for learning the basics of Go.

There are plenty of opportunities for purchase-intent search terms as well. “Golang ide,” “golang mongodb,” and “golang authentication” might all be worth pursuing for the right companies.

5. TypeScript

I was hesitant to move to a new frontend language, but when my team adopted Angular, I was pleasantly surprised. I’m not alone either; TypeScript is the second most-loved programming language according to Stack Overflow.

Similar to Go, TypeScript’s popularity has triggered a surge in search traffic around fundamental search terms. There’s also been significant search volume around the differences between TypeScript and JavaScript, which is more widely used.

Writing TypeScript content is great because you can take almost any interesting idea in JavaScript and swap out TypeScript to come up with ideas. The differences between the two languages are important from a technical perspective, but they solve most of the same high-level problems.

6. Open Source

“It was just five years ago that there was an ample dose of skepticism from investors about the viability of open source as a business model. The common thesis was that Red Hat was a snowflake and that no other open-source company would be significant in the software universe. Fast-forward to today and we’ve witnessed the growing excitement in the space.” - Mike Volpi, General Partner at Index Ventures

Open source software continues to interest developers and non-developers alike. As Mike Volpi points out above, open source companies are leaning into this part of their business as a strength, rather than a hurdle.

When you look at the search data around “open source,” you’ll see a list of business ideas that could all prove successful with content marketing:

open source search engine, 500+ monthly searches
open source video converter, 450+ monthly searches
open source 3d printer plans, 250+ monthly searches
open source dashboards, 250+ monthly searches
open source workflow engines, 250+ monthly searches

If your product has an open source core—or at least a component—it makes sense to use this to your advantage in developer marketing.

Conclusion

Generally speaking, there are lots of good opportunities for search engine optimization in developer marketing. Many companies in the space have historically underinvested in content, but we’re now seeing clients generating hundreds of leads with just a few thousand dollars spent.

If you’re interested in learning more, sign up for a call. I’d love to walk you through our process and help you reach more software developers through search engine optimization.

By Karl Hughes

Karl is a former startup CTO and the founder of Draft.dev. He writes about technical blogging and content management.

Build a Blog that Software Developers Will Read

The Technical Content Manager’s Playbook is a collection of resources you can use to manage a high-quality, technical blog:

A template for creating content briefs
An Airtable publishing calendar
A technical blogging style guide

Download Now!

Hugo vs. Gatsby

Karl L. Hughes — Wed, 08 Sep 2021 17:26:37 +0000

JAMStack, which stands for JavaScript, API, and Markup, is the latest buzzword in the world of web development. It aims to drop the complexity of your system, and helps you to deliver better apps in less time. As with any new innovation in tech, there is a plethora of companies offering competing JAMStack options. How can you choose which is the right one for you?

There are two main types of JAMStack sites: static, in which assets are created at build time ahead of deployment, and directly served when the user creates the website; and dynamic, in which a server creates the content and assets every time a user lands on your site.

In this article, we’ll be focusing on static sites and comparing the two most popular solutions: Hugo and Gatsby. You’ll learn the advantages and disadvantages of each, and which one would be best for your specific use case.

Why Static Sites?

You may be wondering why we have chosen to focus on static sites, rather than dynamic. The static architecture delivers lightning-fast websites and, more than anything, less complex systems with a decoupled frontend where you can consume data from any data source.

What Is Gatsby?

Gatsby is a static site generator that describes itself as a “React-based open-source framework for creating websites and apps.” It has a complete build system that enables you to use web technology to create static files. You will write React code to make your site and consume data through a GraphQL layer. Gatsby will then build your site to create multiple static files that you can deploy.

What Is Hugo?

Hugo describes itself as “the world’s fastest framework for building websites.” This static site generator is written in Go with the idea of high performance in the build process. Hugo has its template language based on HTML that enables you to create your site. It also supports Markdown and other languages through plugins.

What Are the Key Differences?

When comparing the two tools, these are the key aspects you want to focus on:

Learning curve
Documentation
Speed
Security
Flexibility
Scaling
Price
Community

Learning Curve

For a developer, the learning curve is an important aspect to consider when selecting a tool; this will help you define how much time you will need to deliver value to your user.

Gatsby is built on top of React as the “templating” language, so if you know React and JavaScript in general, you are all set to start working with Gatsby. The next step in this curve is to understand how to work with graphql. Gatsby uses a graphql layer to collect the different data sources from various plugins to be consumed by your React code. However, Gatsby does provide many templates or ready-to-use “starters” that can help you avoid the complexity of React and graphql.

On the other hand, Hugo is built with Go, but you don’t necessarily need to know Go to use it. If you choose to use a pre-made template, then your work will be mostly related to TOML files for configuration and Markdown for the content files. Still, if you want to customize your site or build from the ground up, you need to know how to write your templates using Go’s templating system.

So the learning curve depends on your goal:

Do you want to customize your site from the ground up? Then if you’re familiar with React, Gatsby will be a quick choice
Do you want to get up and running with ease? Hugo is a solid choice due to its hundreds of quick-start themes.

Documentation

Every time you are about to start a project with something new, it is a good idea to take a look at the state of the documentation of the chosen technology. As you’ll often have to refer to the official documentation to answer queries, you’ll want it to be easy to use and up to date.

Both Hugo and Gatsby have good documentation that quickly drives you to their corresponding Quick Start guides to help you start.

Gatsby has a full-featured tutorial and in-depth guide that runs you through all the nuances of the framework. A simple view of Gatsby’s documentation seems complete but also can be overwhelming.

Hugo’s documentation can be seen as a smaller collection of guides but still with a lot of in-depth information about the framework’s operation.

So in the documentation front, there’s no clear winner, and it will simply depend on your familiarity with the technology.

Speed

One of the selling points of a JAMStack site is speed, but you need to split this concept into at least two different metrics. Build speed and Runtime Speed.

Gatsby says that the framework is “fast in every way that matters,” while Hugo preaches that they are the fastest tool out there.

Build Time Speed

Since we are talking from a developer perspective and both of these tools leverage the power of the build system to create static sites, the build time speed is a good metric that can be part of your decision.

In this race, Hugo is a clear winner without a doubt. Hugo was built to deliver “blistering speed,” and only takes around 1ms per page. Gatsby, on the other hand, takes a considerable amount of time in comparison.

Build time speed will depend on the number of pages to generate and the latency of the data sources. An excellent way to compare this speed is just by having the same amount of markdown files as a source for both frameworks, with Hugo coming out on top every time.

Gatsby does offer incremental builds inside their cloud service that aim to provide better build times, but at the same time can lead to vendor lock-in.

Runtime Speed

Analyzing the runtime speed can be tricky and will depend on more variables than just the framework. But simply: Gatsby creates HTML pages from your React code to serve the essential app shell and then injects some JavaScript (including React library and any other 3rd party library) to continue the rendering process. This can be seen as slow since there is a JS bundle to load, but at the same time can be an advantage since through this process Gatsby offers other optimizations out-of-the-box such as: Progressive and responsive image loading, and inline critical CSS.

Hugo creates the static HTML pages from the Go templates and includes optional JS compiled with esbuild.

Here the comparison is challenging since simple load HTML and other static assets are fast for both solutions. Still, in some cases, the progressive enhancements offered by Gatsby can be useful or essential to a site, which gives it a slight edge.

Security

Both offer security as one of their selling points; Gatsby advertises that since they generate static HTML at build time, there is no server, avoiding malicious requests, DDOS attacks, or data exposures. But, the same is essentially true for any other static site generator.

You could argue that since Gatsby heavily utilizes JavaScript, then a security issue could arise based on the number of unknown and uncontrolled npm packages involved.

Hugo has a documentation section to talk about the security model they offer. General Data Protection Regulation (GDPR) is an EU law on data protection and privacy, and Hugo describes in detail how to configure your site to meet the regulations.

But in general words, an SSG holds its weight in terms of security from holes that can arise from 3rd party issues. As an example, this is a comment from a vulnerability issue found in postcss, which states:

The issue is not critical (it can affect only online tools like CodePen…)

So in terms of security, you can consider that both frameworks have similar or even equal security features.

Flexibility

What is the level of customizability that each framework offers? Do Gatsby and Hugo let you create what you want, or are there limitations on design?

Here, both frameworks offer full features on customization; Gatsby allows you to create any component you wish with React and any UI library or CSS solution you prefer: tailwind, emotion, or just plain old CSS. Hugo is also free of design opinions, so you are free to implement any UI you wish with the tools available: Go templates and any CSS framework.

Both solutions are equally flexible, so it just depends again on what framework you are more familiar with: React for Gatsby, or Go for Hugo.

Scalability

Scalability is the ability of the framework to handle large and growing sites. Both solutions have their own take on how to confront the challenge.

Gatsby is known for a slow-building process that creates many different pages, so it can be tedious to work with big sites. They even have an entry in the documentation to address this topic in particular.

They mention that they have acknowledged that Gatsby has scaling issues when the application has more than 100K pages or when the graphql queries are too large. There’s even a GitHub issue about scalability where the engineering team recollects benchmark data.

One way they offer to solve this building scalability is with their cloud system, but this is an imperfect solution.

On the other hand, Hugo prides itself to be blazing fast for building thousands of pages, so we can say (again) that Hugo here is a winner if we’re looking purely at scalability of build.

But static sites are built, or updated, way less often than they are read, so the other important point on scalability is how well they behave under heavy load.

The JAMStack is, by default, almost infinitely scalable. Since SSG pre-render the assets, the Time to First Byte (TTFB) is minimal. Also, the files can be served through a CDN and be available almost instantly for the user (and use the great HTTP caching capabilities to make it even faster), therefore lowering the server requirements. Hugo and Gatsby fall into this category of frameworks, so their scalability features are on par. Still, if you consider the built time an essential metric for your scalability needs, then Hugo has the advantage.

Price

Another essential aspect to consider when reviewing tools for your marketing site (or any site for that matter) is price.

Both Gatsy and Hugo are free and open-source. You can download them and use them for free, and the only cost you’ll have to worry about is deployment.

To deploy a site built with Hugo or Gatsby, check some CDN services like AWS, Netlify, or Vercel. Most of these services have a free tier to enable you to start as fast as possible. The other possible cost is related to your data store or CMS, which depends on the service you are using.

So as both frameworks are free, this one is a tie.

Community

With every tool or technology, having an active community can be a huge bonus, particularly if you run into an issue that’s not covered by documentation. In this case, Gatsby is a clear winner, with a thriving and growing community complete with global events and conferences.

Conclusion

Both Gatsy and Hugo do a great job in every category that matters for comparison, with Gatsby drawing an ever-so-slight edge in the community aspect. But, I think it all boils down to your development team’s experience: if your team is already experienced with javascript and React, then Gatsby is an excellent choice to start right away, and if JavaScript is not a tool you have under your belt, then the learning curve of Hugo will be lower, so it can be a great alternative.

Want ideas for your next blog post?

Kickstart your content marketing efforts. Download our list of 50+ winning ideas for your company's blog today.

Download Now!

Running My Business From an iPad

Karl L. Hughes — Wed, 01 Sep 2021 19:17:41 +0000

===

Earlier this year, I decided to get an iPad as a more portable work device. I haven’t owned an iPad since the first generation models back in 2010, but with the larger sizes and full-size keyboard, I figured it could feasibly serve as a laptop replacement - at least for short stints.

I’m going on a vacation later this month, so I figured I would try exclusively working on my iPad for a week, just to see if any parts of my day-to-day workflow were difficult or impossible with it. I shut my laptop down and put it in the closet.

My Day-to-Day

A year ago, I moved out of my job as a startup CTO to become a technical content marketer. I started off doing all the writing myself, which meant creating demo apps, tutorials, and lots of research.

Today, I’ve got a team of full-time and contract employees supporting me, so my role is primarily sales and management.

While I don’t have a “maker’s schedule” of long stints of focus time, I find that I need to do some deep work every day. So, my typical day-to-day is a mix of sales calls, emails, writing, and coordinating projects.

Unfortunately, I haven’t found a great way to write much code on my iPad, so for this trial week, I paused working on any side projects like that.

Despite this limitation, I noticed a few really positive things when I started running my company from my iPad.

I Was More Focused

Having a laptop and a large monitor is nice, but it also means I can have a lot of windows and tabs going at once. This is convenient when I need to rapidly switch between different applications, but it can also be distracting.

I found that working on my iPad meant I was forced to focus on one task at a time, and I was less likely to get distracted by other tabs in my browser. While the iPad supports split-screen, you can’t do nearly as many things at once on it.

This also came into play during meetings. I normally have to shut everything else on my laptop down during Zoom meetings so I don’t get distracted, but since you can’t really do multiple things at once on an iPad, I was forced to focus in on each call.

Delegation Became Key

I’m pretty good about delegating tasks to my team, but working exclusively from an iPad made me take it a step further. I could no longer simply hop into a codebase and fix an error for one of our engineers. Instead, I was forced to leave them comments and delegate the fix back to them.

I also found that working on an iPad made me rethink some of the more complex processes I do on a weekly basis. Many of them were better done by other team members anyway, but because I could do them quickly on my laptop, I had put off delegating them.

It Went Surprisingly Well…

Overall, I’m happy to say that my experiment worked.

There were very few things I couldn’t do on my iPad, even without a lot of preparation work. Some tasks were slower or more annoying, but even with the small keyboard and no mouse, I wasn’t noticeably worse at doing my day-to-day work.

Now, part of this is because my primary job as the Founder of Draft.dev is sales and management. That means most of my work is answering emails, leading calls, and following up with people. I still write every week and mess around with writing code when I can, but those aren’t really my primary functions any more.

Still, I managed to use spreadsheets, presentations, and a lot of other tools that I wasn’t sure would hold up. That said, not everything went smoothly.

…But Not Great

I found a couple things that were simply impossible given my current setup. For example, to preview content for my personal blog, I typically spin up a Docker container that runs Jekyll. Well, there’s basically no way to run Docker on iOS due to the lack of a Linux kernel, so that method is out. Similarly, I found that I can’t test out my CFP Land newsletter before I send it because again, there’s no way to run a dev environment like that on an iPad.

I also couldn’t figure out how to create and upload images on my personal blog. Now, there are some workarounds, but I’ll likely try upgrading to a proper CMS and using a Git-based branching scheme to address this shortcoming.

Spreadsheets also suck on iOS. While I could open and use Google Sheets, you can’t create multi-line cells and the small screen makes it hard to see a lot of data at once. Entering equations is also less than ideal on the smaller keyboard.

Another slowdown I encountered was that Grammarly doesn’t work the same way on iPad as it does on a desktop. Using the Chrome extension, I can edit Google Docs and get real-time feedback from Grammarly, but this same workflow is more cumbersome on iOS.

Some iOS apps don’t provide the same options as their web counterparts. For example, both Trello and Airtable lack certain features on mobile (sharing views in Airtable and the Repeater powerup in Trello), so you have to switch over to the browser interface if you need those features. Not a big deal, but it was annoying. Gmail also doesn’t support templates in the mobile app, so I’m going to have to get another app to handle that.

Finally, the battery life on my 4th generation iPad Air is only about 6-8 hours, so unless it’s fully charged before I start the day, it’s probably not going to make it all day. Normally, I wouldn’t complain about that except my M1 Macbook Pro can basically run for three days of work without a charge, so I’ve gotten spoiled.

iPad: Work Machine of the Future?

For someone like me who’s primarily doing sales and management, it’s possible to do 90% of my work on an iPad. That said, it’s not always very satisfying. Some tasks take so much flipping between apps that they can be really frustrating, and because it still doesn’t handle spreadsheets well, it’s really hard to do long-term forecasting or planning from an iPad.

Still, these shortcomings are really just software problems. The underlying hardware and operating system seem like they could handle these tasks, and the battery life will likely improve thanks to the new M1 iPad chips.

It will take a lot of work for software developers or creatives to ditch their laptops for an iPad, but it’s good to know that I can use it for a short time at least.