DEV Community: Levi Nunnink

7 Open Graph Tag Mistakes That Make Your Links Look Broken

Levi Nunnink — Thu, 26 Feb 2026 16:49:24 +0000

You write a great blog post. Someone shares it on LinkedIn. The preview shows a broken image, a truncated title, and a description pulled from your cookie banner.

This happens way more often than it should. And the fix is almost always the same: your Open Graph tags are wrong.

OG tags are the <meta> tags in your <head> that tell platforms like Facebook, LinkedIn, Slack, Discord, and Twitter/X what to show when someone shares a link. Get them wrong and your content looks unprofessional — or invisible.

Here are the 7 most common mistakes I see, and how to fix each one.

1. Missing og:image entirely

This is the big one. No og:image means no preview image. Most platforms will show a blank grey box or a tiny favicon. Your link looks like spam.

Fix:

<meta property="og:image" content="https://yoursite.com/images/post-preview.jpg" />

Every page that could be shared should have an og:image. If you don't want to create unique images for every page, set a default fallback in your template.

2. Using a relative URL for og:image

This works in your browser:

<!-- Broken for OG -->
<meta property="og:image" content="/images/preview.jpg" />

But Facebook's crawler doesn't know your domain. It needs the full URL:

<!-- Works -->
<meta property="og:image" content="https://yoursite.com/images/preview.jpg" />

This applies to og:url and og:image — always use absolute URLs starting with https://.

3. og:image is the wrong size

You uploaded your 100x100 logo as the OG image. On Facebook it gets stretched into a blurry mess. On LinkedIn it shows as a tiny thumbnail instead of a large card.

The sweet spot: 1200 x 630 pixels.

This works well across every major platform — Facebook, LinkedIn, Twitter/X, Slack, and Discord. Keep the file under 8MB and stick with JPG or PNG.

4. Missing og:title and og:description

Without these, platforms fall back to your <title> tag and <meta name="description">. Sometimes that's fine. But often your <title> includes your site name and separators that look weird in a social card:

"How to Deploy Next.js | My Blog — A Blog About Things"

Set explicit OG tags with clean, shareable copy:

<meta property="og:title" content="How to Deploy Next.js" />
<meta property="og:description" content="A step-by-step guide to deploying your Next.js app to Vercel, AWS, and Cloudflare." />

Keep og:title under 60 characters and og:description under 155 characters to avoid truncation.

5. Not setting twitter:card

Twitter/X has its own meta tag system. If you don't set twitter:card, you might get a tiny "summary" card instead of the large image card you wanted.

<!-- Small card with square thumbnail -->
<meta name="twitter:card" content="summary" />

<!-- Large card with full-width image — usually what you want -->
<meta name="twitter:card" content="summary_large_image" />

Twitter/X will fall back to OG tags for the title, description, and image, so you don't need to duplicate everything. But you do need twitter:card to control the layout.

6. Serving different content to crawlers

Some setups accidentally serve different HTML to bots than to browsers. This happens with:

Client-side rendering: If your OG tags are injected by JavaScript, crawlers won't see them. Facebook, Slack, and most platforms don't execute JS.
A/B testing tools: If your testing script swaps the <title> or meta tags, crawlers might see the wrong variant.
Caching layers: A CDN or cache might serve a stale version of your page to crawlers.

Fix: Your OG tags must be in the initial HTML response. If you're using React/Next.js, use server-side rendering or static generation for your <head> tags. In Next.js App Router, export metadata from your page.tsx — it's server-rendered by default.

7. Never testing your tags

You set up OG tags once, deployed, and never checked. Then your image CDN changed domains, and every link shared for the last 3 months showed a broken preview.

Always test after deploying. You can use the Smmall Cloud Open Graph Checker to see exactly what every platform will display — it shows previews for Google, Facebook, Twitter/X, and Slack side by side, plus warns you about missing or misconfigured tags.

It's also useful to test periodically. CDN changes, CMS updates, and theme switches can silently break your OG tags.

Quick checklist

Before you ship any page that might get shared:

[ ] og:title is set and under 60 characters
[ ] og:description is set and under 155 characters
[ ] og:image is set with an absolute URL, 1200x630px, under 8MB
[ ] og:url is set to the canonical URL
[ ] twitter:card is set to summary_large_image
[ ] Tags are in the server-rendered HTML, not injected by JS
[ ] You've tested the URL in a preview tool

Get these right and your links will look polished every time someone shares them. It takes 5 minutes and makes a real difference in click-through rates.

Built a free Open Graph Checker that shows previews for Google, Facebook, Twitter/X, and Slack. Check your site's OG tags in seconds.

Email files to your own cloud storage

Levi Nunnink — Sun, 01 Jun 2025 00:40:48 +0000

This is a submission for the Postmark Challenge: Inbox Innovators.

What I Built

I build a simple service that allows you to securely upload email attachments directly to AWS S3 simply by forwarding it to an email address. When your inbox gets crowded and you want to keep your important attachments in cloud storage, you can forward your email to <folder>@email-to-s3.email. The service will process those attachments using Postmark's Inbound API and store the files in your own cloud folder on S3.

Demo

Forward any attachment:

The service uploads it and responds with a link to the file in the cloud:

It also stores it under a S3 folder linked to your email address so you can login and retrieve your uploads any time.

Try it yourself

This is just a proof of concept. There are a number of cases where it would be ideal to upload attachments to a cloud folder simply by forwarding an email: customer reports, notifications from internal systems, team collaboration, project management streamlining, etc. This code should be easy to adapt to these and many other use cases.

Code Repository

levinunnink / email-to-s3

An example of how to upload email attachments to S3 using the Postmark Inbound hooks

Email to S3

Lightweight Express.js service that receives inbound emails via Postmark and uploads attachments to any S3-compatible block storage (AWS S3, Cloudflare R2, DigitalOcean Spaces, etc.) under the pattern <email-address>/<attachment-name>. No database dependencies.

Features

Receives inbound email webhooks from Postmark
Uploads attachments to S3
No database dependencies

Requirements

Node.js >= 14
Credentials for your storage (Access Key and Secret)
S3 bucket or bucket-equivalent name created in your provider
Postmark server API token
Serverless Framework installed (npm install -g serverless)

Installation

git clone https://github.com/levinunnink/email-to-s3.git
cd email-to-s3
npm install

Configuration

Environment Variables

Copy .env.example to .env and fill in:

# .env
STORAGE_ENDPOINT=https://<account>.<region>.r2.cloudflarestorage.com  # e.g. Cloudflare R2 endpoint
STORAGE_REGION=auto                             # Some providers may ignore region
STORAGE_ACCESS_KEY_ID=your-access-key-id
STORAGE_SECRET_ACCESS_KEY=your-secret-access-key
STORAGE_BUCKET=your-bucket-name
POSTMARK_SERVER_TOKEN=your-postmark-token
PORT=3000
SEND_EMAIL_RESPONSE=1 # Indicates if the service should send a response email with the

…

View on GitHub

How I Built It

Tech Stack: Node.js & TypeScript, Express.js, AWS SDK v3, Postmark SDK, Serverless Framework
Storage Abstraction: A generic StorageClient wraps any S3-compatible endpoint, using forcePathStyle and custom endpoint for providers like R2 or Spaces.
Serverless: Deployed as an AWS Lambda behind API Gateway, defined in serverless.yml with least-privilege IAM. This should be trivial to stand up on AWS, Cloudflare Pages, or DigitalOcean Apps.
Postmark Integration: Parses InboundMessage, decodes Base64 attachments, and streams each file into your bucket. On failure, returns HTTP 500 so Postmark will retry. Additionally we use the Postmark Transactional API to send email responses with the uploaded attachments. (This can be disabled with a an env variable.)
Developer Experience: Zero database. You just configure environment variables, deploy, and you’re live. Local dev uses ts-node-dev for quick iteration.

Souring on Serverless

Levi Nunnink — Thu, 07 Dec 2023 16:57:33 +0000

For those who don’t know, Serverless computing is a cloud computing execution model where the cloud provider dynamically manages the allocation of machine resources. In a serverless architecture, developers can build and run applications and services “without having to manage the infrastructure”.

The big draw for me as someone who has no desire to ever SSH into a server again was the idea of a “resourceless” function that just runs when I need it. Even more magical was the idea of auto-scaling: The ability to handle any load of traffic without ever having to think about it is tantalizing. And I still think it is… in theory.

Cold starts are killer when you need a quick response

One of the key things to know when building an application is what needs to be synchronous and what can be asynchronous. HTTP is a synchronous protocol, meaning that it needs to answer immediately when someone makes a request. This should have been my first clue that making HTTP requests to an infrastructure that needed to start up before it could respond wasn’t exactly a recipe for success.

The end result is a web application that feels sluggish, where the loading states just linger longer than feels right. You can do static rendering, CDN caching, but if your API has to start up when responding to a request, it’s gonna feel slow.

I really noticed this on Smmall Cloud. That bouncing cloud was just getting too familiar.

The “solutions” don’t really work

When a function is triggered in a serverless environment like AWS Lambda, the platform needs to initialize resources (such as setting up the execution environment, loading dependencies, etc.) before the function can start executing. But then there’s a “warm start” where the resources are already initialized and ready to execute. This happens in a situation where you’re hitting the function multiple times before it shuts down and returns its resources to the cloud. Warm Start vs Cold Start might be a good technical design for AWS but it’s a nightmare for debugging performance on a web application. Think about a situation where sometimes your page loads fast and sometimes it takes forever.

Serverless apps can be configured with “pre-provisioned concurrency”, effectively keeping one or two resources warm and reducing cold-start times. But, in my experience, this still has latency associated with it. And I don’t think I’m the only one.

If you step back the idea of “pre-provisioned concurrency” ruins one of the key selling points of Serverless in the first place: not using resources when you don’t need them. If you have a service that’s designed to shut down when it’s idle but you insert a mechanism to make sure it never shuts down, ask yourself, are you actually using the right service?

Maybe an always-on API is a good idea after all

Finally after being tormented by the bouncing cloud one to many times, I decided to give Digital Ocean a spin and see what they had to offer. Within about 30 minutes I had my API deployed and running on their servers. And guess what? It’s faster. And it’s cheap too.

Thus dies the Serverless dream.

I’ll still use it for asynchronous processing. (The Sheet Monkey ETL works great on Serverless with SQS.)

But moving forward, when I’m building HTTP, it’s back to servers for me.

Sending data from a HTML form to a Google Sheet

Levi Nunnink — Thu, 03 Sep 2020 15:13:27 +0000

I've been running into this situation more and more often where I need to gather user data on a website for things like a mailing list, an opt-in form, or a survey, but I don't have a marketing platform to store the data in. They all have different pricing and features and I don't have time to figure out which to use. I just wanted to append submissions from my front-end to a Google Sheet (mapping fields to column headers) and worry about marketing platforms later. But I couldn't find a good service to do that.

So I decided to build it myself. Couldn't be that hard, right?

Here's how I did it:

Tech Stack

As I've written before, I think the perfect tech stack for your startup is whatever you can use to get the job done fastest. For me that's a variation on the MERN stack with Serverless as the hosting framework.

If you've never built a Serverless app before and are looking for something to get you started, take a look at this boilerplate project I threw together. It's pretty basic but I use it for a lot projects to get things started.

The key considerations as I looked at the project were:

We needed to use the HTTP request to validate the form input and throw a user-visible error.
If everything looked good, that's when we needed to start talking to Google about updating a sheet. And because this was a third-party we needed to interact responsibly and limit our rates.

I've written about this in another article, but SQS FIFO queues are a great way to rate limit interactions with a third party api. So any interaction with Google needed to happen in a queue with a worker function. This is a perfect application for Serverless and FIFO.

Ultimately the basic architecture I had sketched out looked like this:

With this framework in place, I needed to get down to the specifics of each bit of logic.

Working with the Google Sheets API

My HTTP endpoint would be getting a POST payload like:



{
    "DOB": "6/20/1997"
    "Name": "Jane Doe",
    "Email": "jane@applemail.com",
}

I needed to convert that to a sheet like:

The only caveat is that I needed to order the data correctly so the values matched the columns in the sheet and then add it to the end of the sheet. Pretty simple.

Note: All these examples use the Google Sheets API, v4.

https://developers.google.com/sheets/api/reference/rest/v4/spreadsheets.values/append



const { google } = require('googleapis');

class ExecuteSheetUpdateCommand {
  /**
   * @param {string} spreadsheetId ID of the Google Spreadsheet.
   * @param {Object} data Object that contains the data to add to the sheet as key-value pairs.
   * @param {google.auth.OAuth2} auth An Google OAuth client with a valid access token: https://github.com/googleapis/google-api-nodejs-client.
  */
  static async exec(spreadsheetId, data, auth) {
    const sheets = google.sheets({ version: 'v4', auth });

    const rows = [data.Name, data.Email, data.DOB];
    // Add our new data to the bottom of the sheet.
    await sheets.spreadsheets.values.append({
      spreadsheetId,
      range: 'A1',
      valueInputOption: 'RAW',
      insertDataOption: 'INSERT_ROWS',
      resource: {
        values: [rows],
      },
    });
  }
}

Viola! With one simple function we were automatically mapping form data to Google Sheets.

Now obviously this function isn't great. It's coupling the form headers to the sheet structure with this line: const rows = [data.Name, data.Email, data.DOB]; You really shouldn't do that. (For example, if I moved a column in my spreadsheet, this function would keep inserting data into the old location and my sheet would have incorrect data.) But it's a bit more complicated to automatically map form fields to the sheet headers and I'm leaving that part out for the sake of this example.

Adding an REST endpoint with an SQS worker

Ok, so we have a function that can send a JSON object to a Google Sheet but how do we do that with a HTML form? The answer is HTTP + SQS.

The HTTP part is pretty simple if you're familiar with Node and Express. (You could just as easily deploy this on another node-friendly environment but I'm going to show you how to do with Serverless and AWS.) I use the aws-serverless-express package to ship my express apps as Serverless Lambda functions. Combined with the serverless-api-cloudfront package, it's incredibly easy to spin up a scalable API.

Here's an express HTTP endpoint that begins the update to the Google Sheet:



const express = require('express');
const bodyParser = require('body-parser');

// An AWS SQS client
const sqsClient = require('./clients/SQSClient');

const app = express();

app.use(bodyParser.urlencoded({ extended: true }));

app.post('/form/:spreadsheetId', async (req, res, next) => {
  const { spreadsheetId } = req.params; // The Google Sheet ID
  const { body } = req; // The post body

  /* Note: You should run your own custom validation on the 
     * form before forwarding it on. In this example we just continue.
   *
     * At a minimum, make sure you have permission to update the 
   * sheet, otherwise this will break downstream.
     */
  const passedValidation = true;

  if(passedValidation) {
    // Send the data to our SQS queue for further processing
    await sqsClient.createEntry.sendMessage({
      spreadsheetId,
            body,
    });
  } else {
    throw new Error('Invalid form data');
  }

  res.status(200).send('Submitted your form');
});

And then here's the Lambda function that pulls the data off of the throttled SQS FIFO queue and processes it for Google:



const { google } = require('googleapis');
const ExecuteSheetUpdateCommand = require('../commands/ExecuteSheetUpdateCommand');

exports.handle = async (event, context, callback) => {
  const messages = event.record.body;

  // This little logic helps us throttle our API interactions
  messages.reduce(async (previousPromise, nextMessage) => {
    await previousPromise;
    const { spreadsheetId, body } = nextMessage;
    const accessToken = /* Load a valid access token for your Google user */;
    // Construct an oAuth client with your client information that you've securely stored in the environment
        const oAuth2Client = new google.auth.OAuth2(
      process.env.GOOGLE_CLIENT_ID, process.env.GOOGLE_CLIENT_SECRET, null,
    );
    oAuth2Client.setCredentials({
      access_token: accessToken,
    });
    await ExecuteSheetUpdateCommand.exec(spreadsheetId, body, oAuth2Client);
    return new Promise((resolve) => {
      setTimeout(resolve, 1000); // Throttle for the Google API
    });
  }, Promise.resolve());

  callback();
};

The reason we're using SQS with FIFO and not just executing this all in the HTTP endpoint is because it allows us to quickly respond to the user who is submitting the form, and update the Sheet as soon as we can while respecting API limits.

If we don't think about API limits, we could get ourselves into situations where the user is shown an error screen as soon as they submit a form. Not good. The Google Sheets API has a limit of "100 requests per 100 seconds per user", or 1 request / second is as fast as we can safely interact with it.

SQS FIFO queues allow us to put our sheet updates into a single line, grouped by user id, and we can then throttle those executions using that messages.reduce snippet above to make sure that we never go over our limit of 1 request / second / user. And we also get the added benefit of allowing AWS to do the hard work of throttling. The key is when your populating the FIFO queue, make sure the MessageGroupId is set to the Google user id that is making the OAuth request.

Wrapping it up

By using a combination of these techniques and functions, you should be in a place where you can write an HTML form like:



<form action="https://<my-express-endpoint>/form/<my-sheet-id>" method="post">
<input type="email" name="Email" placeholder="Enter your email" required />
<input type="name" name="Name" placeholder="Enter your name" required />
<input type="submit" value="Submit" />
</form>

and data will magically show up in your Google Sheet every time it's submitted:

Sheet Monkey

Ok, that was a lot more work than I thought. That's why I ended up turning this into a little indie product. If you need to send your HTML forms into a Google Sheet and don't want to go to the hassle of building your own solution, check out what I built at Sheet Monkey.

Building a scalable, fault-tolerant Shopify import / export pipeline with AWS

Levi Nunnink — Thu, 23 Jan 2020 04:18:00 +0000

Maybe you've had this problem: Some asks you to build a service that can export a bunch of from a system. Recently I was working on a side-project, a Shopify integration that needed to export a bunch of Shopify API metadata from one store and import it into another store.

It needed to work something like this:

That seems pretty simple, right? I thought so too. "This should take me a few days," I said. "I can knock it out over the weekend." 🤦‍♂️

Here's what I quickly discovered:

Challenge: Exporting big datasets won't work using only HTTP

HTTP is a synchronous protocol, which means that it if it sends a message it requires a response. If it doesn't get a response within a certain amount of time it gives up and throws an error. But my export needed to accommodate pages and pages of Shopify metadata, each bit of metadata needing to be built with multiple API calls. There was no way that I'll be able to build the export file in a time to respond to a single HTTP request.

Even if I was able to put together the raw computing power to do a big export in a few seconds, there was no reason to do so. Important as they are, exports happen infrequently enough that users are fine waiting for them. HTTP was just the wrong application for the task.

The first thing I did was switch to AWS SQS and wire up a DynamoDB table. So instead of my HTTP request trying to build an entire export, it just started an export and would regularly ask if it was done via polling. So the new system looked like:

Much better. This model didn't care how big or small the Shopify data set was. It just issued SQS messages and Lambda workers would assemble the data. DynamoDB kept track of state and would just keep issuing batches of SQS messages until nothing was left to be exported. It would scale.

Or so I thought, but I forgot one thing...

Challenge: Shopify's API is rate limited

The problem with this lovely scalable, asynchronous system was that it was too scalable. It performed like gangbusters, so much that we immediately started hitting the Shopify API rate limit as soon as it tried this with a decent sized store.

The underlying problem with that my process was asynchronous. It would just issue loads of SQS messages, generating loads of parallel lambda workers, themselves generating loads of API requests. It was the equivalent of a hungry mob swarming a single food truck. The answer in both cases is "form an orderly line! We will serve you in order." In the AWS world this is a FIFO queue.

FIFO (first in, first out) queues are special SQS queues that make sure your messages form an orderly line and nobody cuts. For me this meant that I could post as many SQS messages, as quickly as I wanted but my workers would only trigger in sequence, never all at once. The best part of this is that I didn't have to significantly refactor any of my code. I only needed to change the queue type to FIFO, add a few extra parameters to my message, and AWS did the rest of the work. No more rate limit failures.

Challenge: Exports should expire

The last part of this is that I wanted exports to expire within 24 hours after they were ready. But the more I thought about this little feature, the more complicated it seemed. Should I build a scheduled / chron function to query the DB for old records and delete them? That seemed like a lot of work and potentially brittle. That's when DynamoDB TTL came to the rescue.

TTL (time to live) is a lovely little feature of DynamoDB that lets you set an expiration date for a record. Just add a property that says how long the record should stick around. In this case, instead of writing a bunch of logic to do this myself, I let DynamoDB handle the complexity. What could have been hours of development turned into minutes.

Conclusion: Read the AWS docs

AWS is an incredibly broad ecosystem with a lot of features that are easy to miss. Frankly, while the docs are thorough, they don't exactly hold your hand when you're trying to figure out how something works. But if you spend the time to do the research up front, you'll save yourself hours and potentially days of dev work.

In this situation, two simple AWS features, FIFO and TTL, shaved days off of schedule that had already grown more than I wanted.

===

🤓 Hey, if you want to follow along with me as I build a static web host for designers, sign up for the Wunderbucket beta. Let me know that you're from the dev.to community and I'll be sure to put you to the front of the line.

A dev's guide to interviewing another developer

Levi Nunnink — Tue, 17 Sep 2019 23:50:24 +0000

If you're a good developer, at some point someone (likely your boss or co-founder) is going to want to create more of you. And it'll probably be your job to do that. Here's the problem, just because you're an amazing programmer, doesn't mean you have the faintest idea of how to find more amazing programmers. Hiring (not scaling, not architecture, not fundraising) was the hardest skill that I had to learn as a technical leader. And some of my past employees would doubtless agree that I was Not Great At It. My guess is that it’s going to be your biggest challenge too.

If you make a good hire it can change your life; a bad one can sink it. Here’s what I’ve learned over ten years of interviewing:

The interview is your best chance to avoid management

The interview is your first line of defense. If you’re someone like me, the interview can be a very mysterious process. You’ve heard legends about Round Manhole Covers and Whiteboard Binary Trees but you’re not sure how that translates into a successful employee. Here’s how you should think about the interview: It’s your best chance to avoid management.

Good employees will make you feel like you have super powers. Bad hires will make you feel like you’re dragging a tire. They’ll make you read books about management, employment law, performance reviews, and conflict resolution. They’ll tear you away from what you actually need to work on and make you focus on them.

So when you conduct interviews, ask yourself: will this person work for me, or will I end up working for them. Will they make you great or will they make you a manager? Let me be clear: you don’t have time to be a manager. Make sure you aren’t hiring a one-way ticket to just that.

Good first impressions are probably wrong

Let’s mentally picture your first interview:

You’ve put out a job posting, you’ve gathered resumes and picked the ones that look promising. Now you’re in a coffee shop, clutching a notepad, waiting for your subject. You’ve been a little nervous about this interview. You’re an introvert yourself, which is probably why you chose a career that would let you hide behind a computer. Meeting strangers is definitely not something that makes you comfortable--much less meeting strangers to judge their merits. You’ve seen your interviewee on LinkedIn and exchanged some emails but what if they’re a weirdo? What if the conversation has a lot of awkward pauses? “Let’s have a conversation.” you told them. “Conversation”. That’s what you called it. You were too milquetoast to even call it an “Interview”. It felt too formal but what else is this? Every person who walks through the door you mentally compare to the LinkedIn avatar. Then with a little nervous twitch in your stomach, there they are. “Hi.” You extend your hand for a handshake, trying for a firm-but-not-aggressive pressure.

Some time later you’re shaking hands goodbye and this is much more comfortable. You sit back down in your chair and watch them leave the coffee shop and you find that you’re grinning. It ended up being a very pleasant forty minutes. Your interviewee was definitely not a weirdo. They were charming, impeccably dressed, oozing positivity and confidence.You shared some laughs and realized that you both had similar tastes in TV shows and politics. They seemed genuinely interested in everything you had to say. It really did feel like a natural conversation between two peers. They dropped a lot of phrases like “test-driven-development” and “functional programming”. Words appear in your mind “Great Teammate”. You picture them on the “About” page of your website. It seems like they belong there.

Pardon the vivid detail but this has been me during a number of interviews, which led to less-than-stellar hiring decisions. Frankly, it’s the easiest thing in the world to project positive vibes in an interview. Enjoy them while they last because those good vibes vanish quickly if the person is a bad hire. You’ll very quickly be wondering what happened to that charming person sitting across from you in the coffee shop and who is this vampire draining your lifeblood?

If you’re making your first hires, put all your good feelings to the side. Feelings are cheap and they aren’t a good indicator if the person is actually competent.

But I do have one caveat, listen to your bad feelings: If something feels off during your interview, if you had a hard time communicating, if you’re happy when it’s over--pay attention to that. It’s not going to get better. If you have a hard time communicating in an interview, it’s not going to get easier when you’re trying to explain the strategy. If they speak in a condescending tone or become combative, imagine how fun that’s going to be when you’re up late trying to ship a new feature.

So remember mere good first impressions are worthless. Bad first impressions are much more significant.

Conduct a live coding test

Maybe the idea of a live coding-test feels a bit heavy handed, a little bit awkward? Shove these feelings away and embrace your inner jerk. A live coding test is essential to making a good hiring decision.

My recommendation is to start your interview with the ice-breaking, conversational stuff to put you both at ease but quickly move into the coding test. What I really want to see when I do a coding test is what sort of programmer I’m sitting next to. Here’s my suggestions for conducting a coding test that yields real insights:

Inform them ahead of time that you’re going to do a live coding exercise and give them an idea of what it will involve (front-end, back-end, algorithmic). Let them use their own laptop and editor.
Test with real problems. If you aren’t doing a lot of algorithmic programming, don’t have them whiteboard an algorithm. The goal isn’t to have the programmer who can quickly recall their computer science coursework. It’s to find someone who can help you be Great At One Thing.
Allow them to use the internet for reference. Honestly, I can’t imagine why you wouldn’t want to do this. Do you intend to force your team to code from memory? Then why act like this is important in the interview?
Pick three problems for them to solve. Here’s a real set of tests from a session interviews that we did hiring javascript developers: https://codepen.io/collection/nkwJkb/ They range from simple to difficult. I wanted the first test to something that even a decent junior javascript developer would be able to solve. (You’d be shocked at how many got stuck on problem one.) After each test was complete, we’d review the results and talk about their decisions together.

An example task from an interview session:

/* 

1. Load all of the URLs and detect their HTTP response code.
2. When they are all done report back to the interface how many of the functions succeeded and how many responded with status code that wasn't 200.

*/

const urlsToLoad = ["http://codsepen.io/jobs", "/about", "/spark", "http://codsepen.io//nothing-here-to-load"];

These are just suggestions. Maybe you don’t like them, maybe you do. But no matter what, just make sure that a live coding test is part of your interview. Watching how a developer solves a single problem is invaluable. You will save yourself from terrible hiring nightmares the second you start this practice.

Date before you marry

In highly-competitive environments, where engineering talent is scarce this might be hard to pull off but I recommend starting your employment relationship with a contract project. Pick a short project (six weeks, maximum) and see how they perform. Pay them a good rate. The goal isn’t to get cheap labor, it’s to make sure that they’re a good long-term decision.

After the contract is over, assess their work very carefully. Programmers are not static creatures, they will improve over time and add new skills, but don’t expect miracles if the project didn’t go well. If you had to jump in and get them unstuck at any point, that should be a deal-breaker. Difficulty communicating requirements should also be serious red flags. But in the best case scenario you should be able to proceed to full-time employment with high confidence that you’re making a great decision.

Interviewing, hiring is an art not a science, which may irk us technical founders, but there are principles and practices that will help you make good decisions and keep you from disaster. Invest time and energy in your hiring process. Don’t wing it. It’s worth the extra upfront work to find those ideal engineers who will help you be better than you could be on your own.

My name's Levi Nunnink. I've previously co-founded two tech startups and I'm working on a third. If you want to follow along with me as I build a static web host for creative people, sign up for the Wünderbucket beta. Let me know that you're from the dev.to community and I'll be sure to put you to the front of the line.

Photo by: Charles 🇵🇭

I ran a study to see who has fastest page load times: static, hosted, or dynamic sites. Here's what I learned.

Levi Nunnink — Mon, 26 Aug 2019 23:22:15 +0000

There's basically three different ways to deliver a website these days.

Hosted: Services like Squarespace, Weebly, Wix and countless more fall under the "Hosted" banner. The appeal is that that you can build a website without having to know how to code. The disadvantage is that these sites come with limited customizability and if a feature doesn't exist, there's usually no way to add it in. (Just try figuring out how to auto-upload to Squarespace for example.) Because these services all rely on proprietary technology, it's hard to know how they operate under the hood. They're easy to use but they're the website equivalent of living in manufactured housing.
Dynamic: These are websites powered by a Content Management System, using an interpreted language like PHP and storing content in a database like MySQL. WordPress is the unquestionable monster in this group, with an estimated 75 million websites or 27% of the internet being powered by WordPress! In 2019, this is definitely the most popular way to deploy a website.
Static: While this sort of website is as old as the internet, deploying 100% static sites is seeing a resurgence in popularity. Static sites come with some big architectural advantages in security over dynamic sites and they are infinitely customizable as opposed to hosted sites. And theoretically, they should be a lot faster than any other option. But is that the case...?

I'm building a static hosting service for designers and I wanted to it to load pages fast; faster than WordPress and faster than Squarespace. But I wanted to see if that was a realistic expectation. I decided to run some tests on these different methods.

With some Googling and searching around on Censys I was able to put together a sample group of sites, segmented by service. Then it was just a matter of running them through Pingdom's Speed Test service one by one and compiling the results. Here's what I found.

Hosted Sites

I'll be honest, I expected these to perform the worst. Hosted, templated sites always feel slow to me. But the results weren't bad. The average page load for the sites I surveyed was 1467 milliseconds. But where the hosted services really shone was in consistency. When you run a standard deviation calculation on the page load times, the hosted sites only showed an average deviation 485 milliseconds. This was for all sorts of different content, image heavy, text heavy, etc

The service with the lowest average page load time was Squarespace and the service with the most consistent load times (lowest standard deviation) was Wix.

👉 Conclusion: Hosted services are decent on page load times and they are most consistent. I.E. Due to their constraints, they're the hardest to screw up royally.

View Hosted Sites stats on Infogram

Dynamic Sites

I've built a ton of Wordpress sites in my past, I've built a smaller number of TextPattern sites and I think I did one ExpressionEngine site about ten years ago. I include TextPattern and ExpressionEngine here because architecturally they're similar to WordPress and I wanted more data as a baseline. I was expecting this group of sites to load the slowest and this time I was right.

Dynamic sites took an average of 2,343 milliseconds to load. WordPress was the highest, taking an average of 3,081 seconds to load. And standard deviation was much higher for dynamic sites too:

WordPress had a standard deviation of 1,780 milliseconds, the highest out of any service that I surveyed.

👉 Conclusion: Despite their popularity, dynamic sites are the slowest and most dependent on individual configuration (I.E. hosting provider, plugins, caching, etc.). This is partly due to their complex architecture of interpreted language and database lookups that happens on every single page load. Once you mix in a large amount of unmoderated plugins of varying quality, it becomes hard to prevent sites slowing to a crawl. If speed is a major consideration for your site, look elsewhere or proceed with caution.

View Dynamic Sites stats on Infogram

Static Sites

Here's the part that I was excited about. Compared to Dynamic sites, static sites are things of beauty. All of the work happens locally or on a build machine so by the time it gets to a server, the only thing it has to do is serve up an HTML page--no database lookups, no language interpretation, no template compilation. Served over a CDN, this should be blazing fast. And when I tested it, it was. Sort of...

(Because static sites don't come with much of a fingerprint to show who the'yre hosted with, it was tricky to even find sites as samples to survey. I used Netlify's site of the week and then some searching on Censys to find samples for these three services.)

Surge.sh and Zeit Now ended up in a virtual tie for the fastest out of all the static services with Surge narrowly beating Zeit. Netlify came in a little slower on page load times then I expected (even getting beat by Squarespace). The standard deviation results were interesting:

The static sites beat dynamic again but lost out the hosted options by a significant margin.

👉 Conclusion: Static sites are the fastest way to serve a site but it's not a magic bullet. You can lose that advantage if you don't build your HTML to take advantage of static hosting. If speed is your main consideration, make sure that you follow other best practices for optimizing page load in addition to serving a static site.

View Static Sites stats on Infogram

Final Results

And the winners are...

🏆 Fastest Website Load Time: Surge.sh. Runner up: Zeit.
🏆 Most Consistent Website Load Time: Wix. Runner up: Squarespace

And the losers:

😖 Slowest Website Load Time: Wordpress. Runner up: Textpattern.
😖 Most Inconsistent Website Load Time: Wordpress. Runner up: Zeit

View all stats on Infogram

Final thoughts:

If you love websites you should love and hate WordPress. I love WordPress because it's made building websites achievable for millions of users. I love WordPress because it treats its users with respect and doesn't trick them into using a product only to steal their data. In many ways it's a wonderful product. But I hate WordPress because it's the wrong architecture for so many of the sites it runs and, because of this, these sites run unbearably slow. I would venture that millions of WordPress sites (maybe even the majority of WordPress sites), should be rebuilt as static sites.

That's why I'm so excited about services like Netlify, Zeit, and Surge. That's why I'm building my own static hosting service. I want more people to have websites but I want them to be fast websites. The future doesn't belong to the template factories like Squarespace & co, it shouldn't. Things are looking very bright for static sites but we need to make it more accessible to the developers who are using currently using WordPress to build their sites.

===

🤓 If you want to follow along with me as I build a static web host for creative people, sign up for the Wünderbucket beta. Let me know that you're from the dev.to community and I'll be sure to put you to the front of the line.

Disclaimer: Do not substitute one man's results for a legitimate scientific study. There are lots of factors that can affect page load time other than what method / framework you're using. Any framework can be made to load fast and the best framework can load slowly.

Building an infinitely scalable cloud host for less than $5/mo

Levi Nunnink — Wed, 07 Aug 2019 19:57:04 +0000

So I’ve got this idea called Wünderbucket. It’s simple static web hosting for designer / developers who can only write HTML & CSS. I really want to build an app that’s sustainable. And for me sustainable means cheap.

I need a system that:

Costs nothing if nobody is using it. If my idea sucks or it takes me longer to find users then I think, I don’t want to be paying for resources that I’m not using.
Scales up automatically to meet demand. If my idea connects and people start registering, I don’t want to hit bottlenecks. My system should just scale to meet demand.
Scales up affordably to meet demand. This is critical. As the system scales, it needs to pay for itself. I can’t fund an expensive hosting bill for a hobby.

Seeing as Wünderbucket is cloud hosting, this could get expensive quick.

Paper napkin business model

My model is freemium with Pro plans at $5/mo & $60/year. I’m assuming that we’re going to have 99% free users and 1% pro users (pretty standard SaaS conversion metrics). That means $5/mo has to pay for 100 users worth of cloud hosting costs and be profitable. That’s not a lot of margin.

If cloud hosting costs are $2.50 per 100 users, I’ll need to get to 500k users before I could even support a full-time employee. That seems like a lot of users to support without any full-time employees.
But what if hosting costs are only $0.05 per 100 users? Seems aggressive but it means I could get to sustainability around 200k users. Still a lot of users but it might be more doable.

The dynamics of this business are pretty simple: The lower I can keep our cloud hosting bill per 100 users, the quicker this becomes a self-sustaining enterprise. Here’s how I’m going to design this system so it works for me:

What Cloud to use?

There’s really only three options that are worth considering: AWS, Microsoft Azure, and Google Cloud. They’re all fighting for eachother's business and they’ll give you secret discounts so it’s pretty tough to choose.

I’m going with AWS because I’m really familiar with their stack. I’ve used Azure and Google in the past and they would do fine too with the features I’m looking for. This is one of those situations where I need to lean on my past experience and move fast so even if those hosts offer some discounts up front, the learning curve isn’t worth it to me.

Bottom line, there’s not any significant across-the-board pricing advantage between the major clouds. They’re all racing to the bottom with their pricing. Just pick the one that you’re the most comfortable with and has the features that best fit your needs.

Anyway, my pick is AWS.

Web application costs

Here’s where we get into the first strategic decision. My service is going to have a REST API component that clients will use to manage their sites. Clients will need to interact with this API every time they update their site but it’s impossible to predict how often that will be. No matter what, it needs to be quick and respond back to the client fast.

So let’s say I want to host my API web app on a couple of EC2 instances with load balancing. Pretty standard setup.

Ok so with this model we already have a problem: the cost for my web application hosting is $61/mo. That means, I’d need to have 13 pro users and 1,300 free users before this broke even—way above the $0.05 per 100 users Holy Gail. This setup would have to easily support 120k users before it hit that number. I’m not sure two medium instances will be able to do that. And there’s another problem: I’m going to have to manually scale this infrastructure as my service scales: monitor response time, CPU usage, latency. That takes time and attention and more money. There’s a better way to do this.

It’s called Serverless.

So what happens if I build my application logic using Serverless Lambda functions behind API Gateway?

With Lambda I don’t have to worry about a server, I only need to know how much memory an API request is going to take and how long it should run. In my setup, each HTTP request translates to one Lambda invocation. All of my requests are only doing things like DB lookups and responding back to the client (nothing memory/cpu intensive like image resizing, etc) so I feel pretty comfortable using 128MB of memory for each invocation. But how many requests will my users make? Ok here’s some more paper napkin math:

Let’s say each user will update their website 200 times every month. (Seems like a lot but let’s be aggressive here.)
That means 100 users will invoke 20k Lambdas every month. Lambda charges $0.20 per 1 million invocations. That means 100 users will cost me $0.004/mo.

But I also want to use API Gateway so let’s add that in too:

API Gateway charges $3.5/million requests so that would mean that 100 users will cost me $0.07/mo.

The other benefit with Lambda + API gateway is that it automatically scales to meet demand. If nobody uses it. I pay nothing. If more people use it, I pay accordingly. I don’t need to monitor servers and try to match my EC2 instances to meet need. It all just happens. This is much more sustainable.

One more thing though, Lambda and API Gateway have a free tier. It’s going to be a while before I even need to start paying for them. With these numbers I can scale to 25k users before I pay anything.

⚡️ Web application total cost per 100 users (after 25k users): $0.074

Database costs

Sigh, databases. It’s impossible to build a web app without them but they’re almost always the bottleneck and a great source of pain and suffering. If you don’t do backups right, optimize your queries and indexes, and set up replication correctly you can find yourself in a world of hurt. If your app is slow, it’s almost always because of your database. Fortunately my service has a pretty simple data model: we’re just tracking users, websites, and what’s in those sites. A fundamental requirement is automated backups and the ability to restore. A simple data model makes No-SQL a good candidate but let’s look at this with a few different scenarios:

Relational DB (MySQL/PostgresDB): If I go with a db.t3.medium instance (seems small but maybe it will work for my needs) that’s $60/mo. And there’s no “free tier” here. I have to get to 120k users before that becomes profitable. And based on my experience with MySQL, I have serious doubts that this tiny instance is going to scale to 120k users.
No SQL DB (Mongo): Mongo seems better suited to my needs but for the bare minimum—to host it on AWS using their fully managed option DocumentDB on a db.r4.large instance—it’s going to be $245/mo. No free tier. I’d have to hit 50k users before I even started breaking even on the database bill. I’d have to get to 1 million users before this became profitable enough to run at the margins I want. And there’s no way it’s going to scale up without changing instances from db.r4.large.25

So just to start development with any of those databases, I’d be immediately loosing money.

But let’s look at DynamoDB.

Dynamo charges on requests, storage, and backups. Let’s crunch some numbers:

Requests. There’s a pricing difference between read and write requests. My hosting service is going to be read heavy so I’ll guess a ratio of 20% write and 80% read. With my estimate of 20,000 requests per 100 users, the sum total requests would cost $0.054. ($0.05 writes and $0.004 reads).
Storage. The data I’ll be storing is really small, even at scale, so I don’t anticipate going over the 25GB free tier.
Backups. Let’s say that I get halfway to the 25GB free tier. My backups would cost $1.25/mo. This is the riskiest part here because, unless I clean out my data, this cost will just increase over time. Still it’s pretty cheap. I’m estimating that each user will consume about 10KB of storage. That means that backups will cost $0.00125/mo per 100 users.

⚡️ Database total costs per 100 users: $0.05

File hosting

The last part of my service is hosting customer static web files and serving them up over a CDN. This is where things can get really dangerous. What happens if someone hosts a webpage with an embedded video and that webpage goes to the front of HackerNews and gets 200k visits in a single day? I need to be very careful how I structure the free and pro tiers so I don’t get killed with bandwidth and storage. Here’s what I’m thinking:

Free users: 100MB total storage and 100MB transfer/mo.
Pro users: 1GB total storage and 10GB transfer/mo.

I’m building a static web host, not a media service. These limits should be more than enough for the average site with HTML, CSS, JS and images.

For the block storage I’ll use S3 and for the CDN I’ll use CloudFront. (I’ll limit the CloudFront CDN to US and EU pricing just to make things simpler.)

Free S3 storage costs: $0.23
Pro S3 storage costs: $0.23
Free data transfer costs: $0.084
Pro data transfer costs: $0.85

Again at this model, I won’t start even going over the free tier until I break 5,000 users.

⚡️ Data storage and transfer costs per 100 users: $1.394

Wrapping things up

One of the reasons I’ve written this article is that I wanted to show how big of an impact your technology and architecture choices can have on the sustainability of your business. You need to keep costs low when you’re starting out but you also need to keep them low as you scale. If you pick the wrong tech or price things the wrong way, you can find yourself with a hosting bill that you won’t be able to pay. But if you use technologies that are designed for your needs and budget, you can go from small to big while maintaining a healthy profit.

To recap, here’s the ranges of pricing scenarios that I covered in this article:

$306/mo to just start. I’d need to hit 6,000 users before I started to break even. About 300k users before I start making a healthy profit. But I would need to increase my infrastructure to accomodate. It’s likely that at 300k users, I would have be running a $5k/mo infrastructure bill for my EC2 instances and database hosting, giving me a $10,000 profit margin. That’s not bad but it’s barely enough for a full time employee and this system would need constant infrastructure maintenance to continue to grow.
$1.424/mo to start. Automated scaling. Zero server maintenance. Instant profitability, even with small amounts of users. If I get to 300k users, I’ll be able to host them and make a $13,800 profit. The best part is that this would automatically scale up to meet the demand, allowing for investment in the product instead of investing scaling the infrastructure.

⚡️ Final hosting costs per 100 users: $1.424/mo. $3.58/mo profit.

That looks pretty sustainable to me.

===

Obviously there’s other ways to make your business profitable than just picking serverless, cheap technologies. You can raise your pricing, increase conversion rates from free, reduce the amount of expensive features you give your free users, etc. But my recommendation is to go cheap when starting out. Build a business that automatically scales with your success and doesn’t punish your wallet for early experiments. Hit me up if you have any questions. Have fun!

How to pick the right tech stack for your startup

Levi Nunnink — Tue, 02 Jul 2019 20:54:38 +0000

Ugly but effective

You know what sucks? The LAMP stack. On almost every front, it’s a lousy web stack. There’s a real sense of shame attached to the label “PHP developer”. But you know what powered some of the most insanely successful startups in the last ten years? The LAMP stack.

As a technical founder, your job isn’t to pick the “best” web technologies, it’s to pick adequate technologies that will make you best. What is the stack that will be fastest for you to ship a product? If you can whip up a LAMP app in no time, go with that. If you live and breathe Rails go with that. If you love MERN (my personal favorite) go with that.

Originally, Droplr started off as a CodeIgniter app, much to my shame in those days. I remember a palpable sense of embarrassment when I had to admit to some developers that Droplr’s API was nothing more than a bunch of PHP scripts connected to a MySQL database. But who the hell cares? The job wasn’t to build the most elegant API on the sexiest tech stack, it was to upload a file and give a user a link. It was great at that and that was the criteria our customers judged us on. Under the hood it was ugly but it was effective.

So bottom line, you should already know what the ideal tech stack is for your startup and you can stop reading this article Pick what you’re best in.

But here’s the tech stack I would use if I were starting a new project today. This is what is right for me. If it’s not right for you, that’s ok.

Different types of application logic

At the core, every web app is going to contain pretty much the same thing:

Synchronous logic (do this now)
Asynchronous logic (do this and report back when you’re done)
Scheduled logic (do this every hour/day/week).

If your project makes use of HTTP (of course it does), it’s going to contain a lot of synchronous logic. For example. REST APIs are going to be fundamentally synchronous, I.E. I want to query an endpoint and get back a list of objects. There’s no option for a HTTP request to report back later, it needs to give a result as quickly as possible. If it takes too long it fails (or throws a timeout error). Most basic web frameworks (Express, Rails, CodeIgniter) are built around synchronous logic.

But don’t be fooled, asynchronous logic can be just as important. What if you need to write a service that takes a screenshot of a url at five different screen resolutions, in different geolocations, and then shows the result to the user? Most likely there’s no way you can do that synchronously in a single HTTP request. And you don’t really need to: the user can wait until the logic is complete to get the result. It’s an ideal case for asynchronous logic. Chances are, your app is going to need to run asynchronous logic. Your tech should be ready to handle this. Don’t make it an afterthought.

Finally, scheduled logic is something that often gets forgotten but it can be actually very important. How are you going to backup your database? Track daily statistics? Send weekly email digests to your customers? These are all examples of scheduled logic. Maybe you’ll be able to get by for a few iterations without a good solution for scheduled logic but chances are you’ll need it sooner than you think.

On top of all this, whatever solution you choose needs to be fast: fast to develop, fast to deploy, and fast to debug. When you’re starting out, always choose speed over scalability.

If you already have a solution that meets these requirements that you can code crazy fast in, great! Use that one. But if you don’t, I’d recommend Node.JS + Serverless + MySQL/Postgres/Aurora or Mongo/DocumentDB as an ideal choice for your tech stack.

The case for Node.JS

I’m sure there’s reasons to hate Node for linguistic purists but for me this is the language that will most help you be best at one thing.

First the robust NPM ecosystem might have some crap in it but it means that you’ll almost never encounter a problem without a pre-built solution. For example, you won’t have to spend hours or days writing your own date parser/formatter. Just $ npm install moment and you have a better date library than you could have ever written yourself. For every challenge there is a decent to excellent solution. And if in a blue moon, there’s no acceptable solution, you can write your own module and publish it to npm. The beauty of npm is that it radically speeds up your development cycles by letting you focus on what you should actually be working on and results in a cleaner codebase, focused on its one job.

Second, Node’s architecture is almost magical in how well it handles both synchronous and asynchronous logic. Asynchronous Javascript used to result in some ugly code (callback hell is a real thing) but with good support for Async functions and Promises, the end result code is much cleaner. If you’ve banged your head over your keyboard trying to make PHP or Ruby do asynchronous logic, Node will seem like a revelation to you. And Node’s REPL module makes testing and debugging code effortlessly simple.

Finally, Node has the advantage of Javascript. Yes, Javascript is an insane language but it runs just about everywhere on the stack. Imagine what it means to have everyone on your engineering team, back-end, front-end, full-stack, speaking the same language. Think of what that does for code reviews, for knowledge sharing, for best practices, for recruiting. Ultimately the result of a standard language means that you can stay fast as your team scales. Speed doesn’t stop being important as your team grows, it just gets harder. But Node.js + Javascript helps.

The case for going serverless

When I started at Riskalyze and Droplr, one of my first tasks was provisioning a server in our cloud, installing and compiling dependencies, configuring firewalls and security. We had a document as long as your arm in our private Wiki with all the meticulous steps to set up a new production API instance. Did I enjoy server admin? No. Was it time consuming? Yes. Is there a better way? Hell, yes.

If you haven’t heard of Serverless, I bet you can guess what it is by the name: Serverless is a Node framework that lets you write functions simply run in the cloud without a server. It cuts out the server admin part of building and shipping a web app, it removes scaling from the equation (at least for a while), and deployment is a single step. It makes shipping a fully functional app fast. And remember, speed is everything.

One of the beauties of Serverless is that it fully supports synchronous, asynchronous, and scheduled logic. It’s trivial to ship code that is triggered by a HTTP request, or a SNS notification, or a cron schedule. In one package it contains all the features you’ll need.

You might be thinking, “that’s great but I don’t have an AWS cloud on my desktop, how do I develop an app without pushing every change to the cloud?” That’s where the flexibility of Node leaps to the rescue. For HTTP functions, you can easily run those on a local port like any other http app. For functions that rely more on AWS services (say they need to be triggered by a SNS message), I recommend running localstack.

There’s a lot more that could be said about Serverless. At Droplr we’ve done a lot of work internally figuring out some best practices around this. For further reference, check out my sample project that gives examples of synchronous, asynchronous, and scheduled logic: https://github.com/levinunnink/serverless-boilerplate You can use this as a starting point for your own serverless app.

What about the database?

As I previously mentioned, when I started at Riskalyze we used MySQL, which ended up being a great choice. Riskalyze is a fintech company and financial data is highly structured and relational. It was crucial for us to be able to join and roll up data based off of different schema keys. Postgres would have also been a fine choice. At Droplr we have a much simpler data set and we ended up going with MongoDB. This also turned out to be a good choice as it allowed us to store huge sets of data without enforcing a rigid structure and needing to constantly migrate our data (very nice if your model is going to evolve with your company).

Ultimately, the best answer is to pick what is going to be fastest for you. What’s going to be the easiest for you build schemas, write queries? Go with that one.

The one thing that I’d strongly recommend is that whatever database solution you choose, make sure it’s managed. I.E. you’re not the one managing it. For every major database there’s a fine managed option available. You shouldn’t be the one worrying about backups and replication. Pay the money and use a service that will handle these things for you. You need to focus on being best at one thing, and that one thing isn’t database administration.

===

All of these are just my suggestions. The beauty of being a technical founder is that you get to pick the technology and as long as it allows you to be best at one thing and adequate everywhere else. Be proud of your tech stack. Let other people hate on LAMP. You go forth and ship your product!

If you want to stay in touch or would like to chat about some of the stuff I brought up in this article, hit me up on Twitter @LeviNunnink. I'm here to help.