Market for Jekyll Developers - A Site Owner's Thoughts

There have been several discussions here about the market for Jekyll developers. Rather than add on to an existing thread, I thought I might post separately. This will be longwinded, so you might want to skip down to the summary.

I am not a developer, but a site owner. I have built a number of sites over the years and can follow html, css, and general JS. Several years ago I began building a site with Drupal. The learning curve was steep. About the time I would get to the 90% level a new version came out and had to start over. After deciding Drupal was for the hardcore, and seeing what it would cost for an outside developer, I gave up. A few years later Wordpress had added a number of the features I needed. I hired a well respected firm to build the site. It worked great on day one. I added content over several months ( needed a large content base to go live).

As it was part-time, I worked on it 2-3 times per week. Each time I opened the admin page there was a theme, plugin, or security update to install. Perhaps, not the command line, but I was adding things that I didn’t really understand. There had to be a better way.

About this time I read an article about static site generators and the ability to add services to fill out the site such as google calendar, discus, etc. Thus began a re-evaluation of my needs. My basic needs were fairly strait forward (I really didn’t need a clone of the Huffington Post). Jekyll seemed to be a viable option.


I don’t need Jekyll, I need a site. Jekyll has a tagline of “Blog Like a Hacker”. My philosophy is “Blog Like Your Best Buddy is a Hacker™”. I hired a competent developer to integrate the various items and technologies. Everyone is on a budget, but your budget can’t be $0.

Jekyll provides a great base to build sites with. Add what you need from a trove of services. Switch when better tools are available.

Talking Points when dealing with Clients
A few of the reasons I chose Jekyll.

  1. Jekyll is all but un-hackable. They have to hit the server. Github and CDNs are much better prepared to fix problems than I.

  2. Static is fast. It doesn’t get faster than html and css. A few seconds of build time are better than a few seconds of page loading for each visitor.

  3. Not limited to other’s templates.

  4. Most services are available thru an API. E-commerce, comments, discussion boards, etc are available, many for free or at reasonable cost.

  5. HTML and Markdown are easy to hand off to others. (my site will eventually end up at a university or research institution). Future maintenance will be simplified.

  6. No database. Everything can read a text file.

  7. Jekyll is what the developers choose for their own sites.

The Market for Developers
I do marketing and new product introduction for construction related companies. Contractors have very small corporate level staffs. They need the following:

  • Contact Info Page
  • About page
  • Company history page
  • General product pages
  • A few new product pages
  • Meet our People Page (sales reps mostly)
  • Portfolio (job stories) pages [maybe]
  • A news and announcement page (the BLOG) for
    1. Recent projects (client A benefitted from product X and you can too)
    2. Employee changes
    3. Announcements (see us at Booth 22 at the Industry Convention)

Doctors, Dentists, and many others would be served by something similar. There must be tens of thousands of B2B firms that need a site well within the capabilities of Jekyll.

What they all need is:
An obligatory web presence
A simplified content entry method (several are available)
Well written instructions
Some minimum training
A call every few months to check on progress, needs, and recommendations.

This is longer than I planned. Hope it helps the developers out there.

1 Like

Hi there,

All of the reasons you have outlined here are my everyday motivators to complete the project I’m currently working on - which lets you forget all the burden of setting up & configuring Jekyll or dealing with obscure deployment or runtime errors and such.

As a software engineer I’m building a long list of open-source custom plugins, themes, setting, my own plugins and such to enhance each & every Jekyll instance running according to the customer needs and business requirements.

All of that stuff is validated, fixed (if needed or abandoned) and curated to work out-of-the-box. You, as a customer, is able to get up & running a Jekyll instance in a single click. Moreover, from the day 0, it is priority #1 to treat an every customer with exceptional support that spans EVERYTHING that you have to do with Jekyll…

  • Did you get lost tweaking that tangled CSS, SASS, LESS, COFFEE or JAVASCRIPT? Drop us a note and we’ll help you out with that;
  • Not sure how to enable Disqus, Google Analytics, custom analytics and such? Drop us a note and we’ll help you out with that;

… and etc.

Moreover, since I’m literally building the service on top of the open-source community efforts, including plugins, themes and etc., the plan is to give all the publicly recognized credits and shoutouts to the actual human beings, be it a plugin hacker, purrfect HTML/CSS theme author or anyone who has put in their time, energy to do things for Jekyll community.

The service described is still in the works but I would love to get it into the hands of live users as soon as possible. If you are interested to have a sneak peek or be a beta customer, feel free to drop me a note.

1 Like

Me SW eng too :wink:

But I have had it with plugins, open source or otherwise. Every plugin will eventually fail. Usually when neither I nor the original developer has the time to fix it.

Webservices are a good option, but even they can fail, go out of business or simply stop offering their services (or demand payment).

So I have chosen another approach: I will do everything myself. No more plugins or services.

The route I have chosen is to build my own server and integrate that closely with Jekyll.

In doing so I have reduced my dependencies to: Jekyll, Html, Css and Swift (Xcode). I wrote my own server that integrates with the websites. No DB, no services, no plugins. The server will inject HTML code into the pages it services to take care of the dynamic aspects. It does so by scanning the pages for ‘functions’. And when found, to replace the function by the HTML code it generated. The function itself is a precompiled piece of Swift code that runs as part of the server.

While it is not at release 1.0 just yet, it is running and I am already testing it. It should be ready for beta use in the next few weeks. If anybody is interested, all the code is open source.

GitHub - Balancingrock/Swiftfire: An extensible HTTP(S) server written in Swift that allows HTML code injection by Swift functions. or

(Documentation is a little behind but usable)

1 Like

Hey there,

I can totally relate to your experience with abandoned open-source projects. However, I simply could not let it go… :slight_smile:

By the way, I looked at your project and I think it is totally awesome! I love Swift and imho it is one of the greatest things ever happened to Apple!! :blush:

I have read thru Swiftfire’s codebase and really want to give it a spin for a few reasons. First, I love the idea of static-aware web server - it’s just brilliant (!!!)… Second, anything written in Swift is simply amazing by default (even nyan cat’s animation :slight_smile:)… Third, I collect static site generators and now I also collect static site web servers!

Love your project!