markdown guide

I work at an agency where we spin up a lot of projects very fast. A lot of our projects we build on Wordpress on a very plain boilerplate theme with some development basics set up (e.g. asset compilation, build tools, CSS post-processing, minification); the front-end developers also have an internal "base" repository to start from with build tool presets and the same file structure as we use for the eventual Wordpress theme. We're also working on building out more internal documentation, tutorials, and a library of the way we've implemented certain components in the past that our co-workers can reference.

Of course, the other component of this is setting a realistic time frame with the client, determining which pieces are the most important for a timely launch, and making sure that those get done before agreeing to add anything else to the project scope. In my experience this is about just as important for getting something done in a timely manner as all the developer time-savers we've figured out.


I think it's always hard to estimate the right amount of time for everything as a beginner, but I have learned that using the time to properly design things both in terms of UI/UX and functionality or flow charting and listing out model and service items really does make developing faster and smoother.


When I was working on one-off freelance static sites, using a CMS was the easiest way to go. It allowed the totally non-technical company the ability to update basic info which was the most important requirement.


Recently I really got into Gatsby. It’s a static site generator offering all the goodness of React and an easily customizable set-up. Many things are taken care of behind-the-scenes to help you create very fast modern sites in a reasonably short time. You might choke here and there with your first project, but once you got the hang of it, there’s no limit to the sky. The plugin library and the number of cusomized scaffold-helpers are growing too.


I've only ever worked on personal websites or sites for assignements and I'm not heading into Web developpement (at least for now) so take this with a grain of salt.

But even with little experience I've been able to recycle parts of projects because they were :

  • Using the same framework
  • Doing similar actions
  • Used for an intranet where an original design was not required

I'm very disorganized IRL but try to have healthy/organized developpement environments and coding habits. As much as possible I try to keep my code modular so that I can reuse parts that I feel can have more than one use.

The most concrete example would be user sign up/sign in/sign out functions. I keep databases different and have different table names and column names for each project but the functionnalities are the same so I don't have to write it from scratch each and every time !

I end up saving quite a lot of time on both the conception and the implementation phases.

Another thing is that by force of habit you'll be able to do more things faster so I guess practice is key.


The agency I work for builds on expressionengine, statamic, Craft, WordPress, Magento, and Shopify. Basically whatever platform fits the needs of the client.

We have built a boilerplate template for expressionengine and are working on one for WordPress.


Having your tooling & workflow figured out is helpful - I typically start a new project by copying my package.json and config files from a recent project - but an even bigger factor is working with your client.

Client management & communication has, for me, had just as much of a learning curve as learning to code.

Putting together a concrete statement of work and timeline can be tedious, but it's a crucial step. In addition to defining what you're delivering, and also what the client will need to deliver to you, the biggest benefit is that it gives the client a sense of what it will be like to work with you.

Here is a sample statement of work & timeline that I put together for a new client.

In terms of getting things done on time:

  • Let your client know that you're going to be working with them, and you'll need their input and content in a timely manner. You'll need some flexibility with your calendar, and they will with theirs, so be sure to factor this in.
  • I like to separate the project into milestones that define when certain things are "done". This can be helpful for limiting scope creep: if I'm working on milestone 2, and the client requests a change to something that was completed in milestone 1, having these points defined will help you explain to them what it would mean to make that change.
  • Most importantly, don't rely on your client to provide final content, or at least as much as is feasible. Work with mockup content, and give them access to a CMS that allows them to replace this with the final content when they have it. Lastly, make it known that the project is "done" when it's content-ready - their final payment should come at this point, don't wait until the site is live.

"In time" depends on what amount of time you've budgeted for the project and what challenges you face. Keeping on time is usually a matter of having good estimates and being able to stick to a timeline.

The most efficient way to do this is to use a tool like GitHub Pages for static hosting, or a site builder platform like Wix or Squarespace.

It really depends on your workflow. Static sites can be constructed using templates and then "baked out" as static files, that offers the most flexibility, but some site-builder platforms have similar proprietary tools to do the same thing.

The important thing is to get a good workflow going where you know all the steps, you've done it all before, and you know the limitations of the platform so you don't inadvertently commit to work that's going to be way too hard to finish on time.

Before you use a new, unproven tool on a job at least give it a spin on a test project. You may find it's way easier or way harder than you anticipated.


I've yet to build a full site from scratch in my spare time, but for a quick landing page, I start with Bootstrap. I also use Wordpress.


A lot of people use something called "Framework" like Symfony or Laravel with PHP or Ruby On Rails with ruby. That makes Website creation easy and fast.


I use bot, I can build a 100k lines website in a month if not less.


I make my own boilerplate to reuse between multiple projects.


that is pretty common as you build more projects, isn't it?

Sloan, the sloth mascot Comment marked as low quality/non-constructive by the community View code of conduct

I think it different to dome developers, some like building from scratch, while some use templates and edit it to their choice.

Classic DEV Post from May 28

Those silly mistakes we all make

Silly mistakes happen to us all.

David Okpare profile image