DEV Community: David Miranda

Build your first Remake app

David Miranda — Wed, 17 Mar 2021 15:03:33 +0000

This is a story of two problems and two solutions.

My first problem was a problem of my own creation. I read a lot of blog posts online, many of them so good that I save them for later, to re-read and share. I started with a simple page on my website where I just kept a list of those links, and why I enjoyed them. But eventually, the list became slow and annoying to update manually — I wanted an app.

That’s when I came upon my second problem, which was very much not my own: Even for something super, super simple, like I want a page on the Internet where I can share an updated list of links, it takes a lot of work to get something working. The road from idea to prototype is covered with excuses not to build, and I’m sure you’ve felt the same problem.

Remake sweeps away those excuses. I took a few hours on a Friday to sketch out an idea for Shelf.page and build it with Remake.
A preview of the shelf.page web app
Shelf.page is representative of a really common kind of app. Every user gets a profile or account page at a unique URL, with a bunch of fields to customize their page and edit it themselves.

Remake shines at building these kinds of apps.

Normally, I would spend the first hour or two of starting a project like this: installing tools, setting up a database, and connecting all the components together, but Remake let me build a full-stack app while focusing on just frontend code. This, combined with one-liner deploys and fast builds, makes Remake rocket fuel for building these kinds of single-page apps — I finished Shelf.page in about half the time I expected it to take!

The rest of this post is about Remake, and how it could cut down your time-to-launch to help you build faster, too.

If you already know what Remake is, and want to just get started with code, feel free to skip down to the Create Remake section.

What’s Remake?

Remake lets you write an app by describing your idea in annotated templates, not writing boilerplate code.

When you get down to it, Remake is a framework. And frameworks are always about abstracting out some repetitive, common part of projects. So a good way to understand Remake is to ask, what does Remake abstract for you?

In my experience, Remake is built on three big ideas.

1. Describe your app with annotated templates

The headline feature of Remake is that you can describe your entire app in a few templates. Remake looks at the shape of your data, and some annotations you add to your template, and takes care of making data editable and interactive in your page.

We’ll dive deeper into Remake’s annotations (attributes) later in the post, but here’s a taste. Let’s say you want every user to have an editable “name” field on their account. You can write a template with some attributes, like

<div class="user-name"
  object
  key:name="@innerText"
  edit:name
>{{ name }}</div>

This tells Remake that:

This field is a property on the user’s account object (object)
This field should be stored under the label “name” in the user’s account (key:name)
This field should be editable on the page, for the account owner (edit:name)

There are a few more directives that combine together to add a layer of editability over your app that’s smart enough to know how you store your data. Combined with Handlebars templates, Remake gives you a way to create fully interactive, editable web pages with just templates sprinkled with annotations.

Write templates that describe how your data relates to your UI, and Remake does the rest. This is a core idea of Remake.

2. Zero-config user accounts and emails

I’ve made lots of side projects over the years, but every time I start a new one, I always need to stop and ask myself if I want to support user accounts, because authentication and account management is an evergreen hassle. Even for prototypes and quick hacks, setting up a database, creating login flows, copy-pasting code from some other project to remember how to implement login securely … all of this takes time, and none of it adds to the actual functionality of the idea I’m trying to bring to life.

Remake apps know how to set up and manage accounts, so in building my own Shelf.page app, I never had to worry about setting up an authentication system. Because I also deployed through Remake’s CLI and platform, user accounts just worked — password resets, login, account pages, the whole thing.

There’s a tradeoff to this zero-configuration setup: There’s not a whole lot you can customize about the login process. It doesn’t support logging in with Google or Apple accounts, for example, and doesn’t support two-factor authentication. But until your idea grows out of the early phase of getting some traction, having to worry little about account management will probably save me hours off each project, and add years to my life.

3. Opinionated ecosystem for one-liner deployments

A lot of the strengths of Remake like zero-config accounts, smart templates, and easy deploys are possible because Remake is opinionated about how your project should be set up.

Like Ruby on Rails or Create React App, Remake comes with a CLI that helps you set up a Remake project. If you follow Remake’s conventions about where files go and how pages are rendered, in return Remake’s CLI also gives you a local development server out of the box and a way to deploy a production app to Remake’s deployment service with a CLI one-liner, remake deploy.

A second benefit of an opinionated design is that, if you have multiple Remake projects, you’ll never have to open up an old project and sit there trying to remind yourself where you put the exact file or page template you’re looking for — every project is roughly structured the same.

Taken altogether, by having a clear, opinionated model of describing how your data is related to your UI, Remake lets you write an app by just describing your idea, not wiring together lots of boilerplate code.

Let’s see how these pillars of Remake come together to actually help build a real app.

Create Remake!

Every Remake project starts the same:

npx remake create shelf

npx is a package runner for NPM libraries — it helps you run commands from NPM packages without installing it globally.

Here, I wanted to create an app called shelf, but you can pick your own name. Once we run the command, Remake will make a new folder named shelf (or a name you pick) with a starter Remake app inside. If you’ve used Create React App, this might feel familiar.

To test out the starter app, we can cd into the new project and run the dev server:

cd shelf
npm run dev

Remake will take a second to build the app, and start running the app at localhost:3000. Visit the URL on your computer to see the starter app, which is a Trello clone. You can also find this demo on the Remake website. It should look like this.
Remake Trello clone web app
Try using the starter app to get a feel for how Remake apps work. Try adding, removing, and saving changes. Here are a few things I noticed in my brief tour.
Remake's built-in edit popover

You can click on titles of stacks or task items to edit the text inside.
When you edit some text, a modal opens with buttons to save, cancel, or (sometimes) delete the item.
You can drag-and-drop to reorder items in a list.

This is no Netflix, but there’s enough here to build many kinds of apps. Adding, removing, and changing things are the building blocks for everything from blogs and todo lists to personal dashboards.

Let’s see what code makes this app possible by visiting app/pages/app-index.hbs.

In the app-index.hbs file, which is a Handlebars template, we’ll find an HTML template sprinkled with attributes like object and edit:. You might have a guess as to what some of these attributes do, but for now, all we need to know is that these attributes are key to how Remake associates your app’s data with the template.

When you change the template and reload the page in your browser, you should see any changes in the template now reflected in the page. Try tweaking a few things before we explore the rest of Remake, like changing the “Add stack” button’s text.

A tour of Remake

Before diving into building an app with Remake, we should understand what goes where in a Remake project.

Static files in app/assets

Every web app needs to serve assets like images, JavaScript files, and CSS stylesheets. These are saved in app/assets under their respective folders.

Page templates in app/pages

If you’ve been following along thus far, you might have a good guess about what these files do — they’re templates for pages in your app.

For now, we only need to worry about app-index.hbs, but here are what the other pages do.

index.hbs: The “index page” of your app, when the user isn’t logged in (as opposed to app-index, for when the user is logged in).
user/ templates: Pages related to account management, like login/sign up pages and password reset.

Most of the time, you’ll be editing app-index.hbs. You can also add other pages next to app-index.hbs to create new static or dynamic (templated) pages for each user. This might be useful if your app has multiple pages or a sub-page for a particular piece of data, for example.

Root templates in app/layouts

You might have noticed that pages in app/pages don’t contain HTML boilerplate code like the page head. This is the responsibility of app/layouts/default.hbs, which defines the app “shell” into which all your pages are rendered by Remake.

User data in app/data and _remake-data

Remake stores user data in data/database/user-app-data as JSON files. For example, for my user account with the username “thesephist”, Remake will create a thesephist.json in which to store all my account data.

If you’re used to storing data in a relational database like Postgres, this tradeoff means a few things.

Inspecting, editing, and debugging data is trivial, because you can just open the files to see how Remake sees your data.
On the downside, storing data in files doesn't necessarily provide the same scalability and durability guarantees as a production-grade database.

For the kinds of apps I’m making for myself and a small number of users, most of the time, the advantages end up outweighing the costs. Under app/data, we can define a default user data file that every new user will inherit, when they make a new account.

Thinking in Remake

Remake started “clicking” for me when I learned that most of building a Remake app is finding a way to map a user’s data to parts of the user interface. I call this thinking in Remake.

When a user requests a page from a running Remake app, what actually happens?
How the parts of Remake fit together
After authenticating the user, Remake…

Fetches the data file ({user-name}.json) for this user
Finds the Handlebars template for the requested page
Renders the page template with data from the user’s data file, and sends it to the browser, along with small CSS and JavaScript bundles for Remake’s UI.
The browser then loads the page, and Remake’s scripts crawls the page for any elements annotated with Remake’s attributes to understand how the UI maps back to the user’s data. When the user makes any edits to the page, the annotations tell Remake how to save those changes back to the backend.

A key piece of the puzzle to understand is that the template tells Remake how to render the page from the data; Remake attributes tell Remake how to save data back from the page’s UI.

Because of this, a good first step to building a Remake app is to map out how your user’s data connects to your UI. For my Shelf.page app, I started with a schema like this:

{
   "displayName": "Linus",
   "bio": "Student, writer, fan of the 90s",
   "topics": [
      {
         "name": "Tech",
         "links": [
            {
               "label": "Remake",
               "url": "remaketheweb.com"
            },
            {
               "label": "Mozilla",
               "url": "mozilla.com"
            }
         ]
      },
      {
         "name": "Community",
         "links": [
            {
               "label": "Get Together",
               "url": "gettogether.world"
            }
         ]
      }
   ]
}

A user has a display name and a short bio, and owns a list of topics. Each topic has a name for the topic, and a list of links under it with a label and a URL.

This shape of data maps really nicely to Shelf.page’s UI.
The parts of the shelf.page application
Once we’ve sketched this out, the work that remains is to express this in code! First, we write a Handlebars template for this page — this lets Remake render our page.

Second, we add Remake attributes to our template, so Remake can save any edits. This is the topic of our next section.

Remake attributes

Remake attributes have a lot of flexibility, but to get started, you’ll probably use them in a handful of useful combinations.

1) Editable text fields

Most commonly, you’ll want to make a text field editable. In our example, we might want the user to be able to edit the displayName property of our user data object. This takes three attributes.

<div  
  object
  key:display-name="@innerText"
  edit:display-name:without-remove
>{{ display_name }}</div>

Here, we tell Remake we’re talking about a property on a JSON object (object), specifically the property display_name (key:display-name). Then we make this field editable, but not removable, with edit:display-name:without-remove.

2) Lists of things

The next common case is a list of things. For example, you might want to add a task onto a todo list. If we have data that looks like below…

{
   "topics": [
      {
         "name": "Computer science"
      },
      {
         "name": "Writing"
      }
   ]
}

...and we want to show a list of editable topics, we’ll use these attributes.

<div 
  array
  key="topics"
>
  {{#for topic in topics}}
    <section 
      object
      key:name="@search"
    >
      <div 
        target:name
        edit:name
      >{{ topic.name }}</div>
    </section>
  {{/for}}
</div>

There’s a lot going on here, so let’s break it down. As you follow along, consider how the hierarchy of the template matches the hierarchy of our data.

At the top, we tell Remake we have an array (array) of things at the property “topics” (key="topics"). Within this div, Remake will consider the array the “root” of our data.
We use Handlebars template notation to render an array of things {{#for topic...}}
Each section element corresponds to a single item in the array of topics, which is an object in our data. We tell Remake this with object. key:name tells Remake to “link” this element to a particular editable field, which will come in handy next.
Finally, we have an editable field for our topic names. We make this field editable and deletable with edit:name. What happens when we delete this field? Deleting this field will delete the whole topic (the whole section element) because the topic is the closest JSON object that Remake could find in our data.

The target:name Remake attributes are the key to this pattern. It tells Remake to link one editable field to another part of our template.

3) Adding an item to a list

The last pattern to know is a button to add more items to a list. Given our template for a list from before, adding a button is straightforward.

<div array key="topics">
  {{#for topic in topics}}
    ...
  {{/for}}
</div>
<button new:topic>New topic</button>

Here, we added an element, outside of our loop with the Remake attribute new:topic, which tells Remake that clicking this button should add a topic item to our templated list of topics.

These patterns were enough for me to build Shelf.page, and will help you get started making Remake apps. But if you’re interested in the full breadth of attributes offered by Remake, you can check out Remake’s data attributes documentation: saving data, updating data, reacting to data.

Finishing touches and debugging tips

Once we have the basics of the app working with a template, there are a few finishing touches you might want to add. You might also run into some bugs you’re not sure how to start fixing. Here are a few tips I picked up shipping my first Remake project.

JavaScript. Remake will not compile your JavaScript or CSS with Babel or SASS, but you can set those up yourself. Just make sure all your transpiled files end up in the assets/ directory.
Layouts. If you want to customize the “shell” of your app outside of the contents of page templates, you can update app/layouts/default.hbs to add any stylesheets, script tags, or metadata you need.
Debugging data. If you suspect Remake isn’t saving your data the way you expect, a good place to check is data/database/user-app-data, to see how Remake is saving your changes. If the data in the user JSON file isn’t shaped the way you expect, you could narrow down your search for the buggy parts of the template.

Deploy!

Once you have a working Remake app, deploying is fast and simple on Remake’s deployment platform. From the root of your project folder, simply run the command

npx remake deploy

and Remake will copy the right files up and spin up your service! If this is your first time deploying, Remake might ask you to create an account.

That’s it! You’ve deployed your Remake app, hassle-free. Try it out by going to your new domain and creating an account!

Do more with Remake

We’ve explored the basics of Remake in this post, but Remake is still growing and improving. For Remake the framework, a cleaner project layout is in the works, with nicer error messages and better documentation. For Remake the tool and deployment platform, you can expect new features like custom domain support in the future.

I’m really excited by how much faster I am at building simple apps when building with Remake, and I’m looking forward to how Remake grows in the future. If you, like me, have a few too many ideas for the hours in a day, consider building out your next hack on Remake.

Guest post written by Linus Lee. I'd highly recommend following him for more hacks, insights, and cool projects.

Hacking Hypertext

David Miranda — Wed, 02 Sep 2020 15:44:48 +0000

Have you ever wondered: “What if clicking on a hyperlink could transport me — not just the screen in front of me — to a new location?”

That’s what the founders of Uber wondered. So, they transformed an ordinary link into a request for a ride.

This is called “hacking hypertext”.

Imagine, a link—a button, a menu, a search result—being able to accomplish something amazing with a single click.

Google is a great example of this. They hacked hypertext in two ways: 1) They realized a hyperlink to a page meant it was valuable and 2) They gave everyone access to these valuable links with the click of a Search button.

Facebook took hyperlinks to the next level by making them represent people and their relationships. Events, messages, profile pages, relationship statuses — all available with a single click.

Who else has hacked hypertext?

Amazon has 1-Click ordering that makes products show up at your door within a couple of days
Airbnb lets you rent apartments around the world with a click
Netflix makes thousands of tv shows and movies accessible with a single click

These companies transform the good ol’ hyperlink into something incredibly powerful.

For most of us, though, links are still just plain, boring links.

As an ordinary person on the internet, I can’t create a link out of thin air that will show a list of my upcoming events or let someone rent my apartment — I rely on Facebook and Airbnb to allow me to create these kinds of links.

So, the question is: why isn’t hypertext more powerful by default?

The answer is: it’s wildly expensive to transform an ordinary hyperlink into something more.

Big companies like Google and Facebook spend billions of dollars a year building the infrastructure and hiring the talent necessary to support their hypertext hacks.

Usually, the most an ordinary citizen of the internet can do is link to a social media profile or personal website.

But... what if someone decided to democratize the incredible power these big companies have to hack hypertext?

What if anyone could hack hypertext?

More and more companies are buying into the “Low-Code” movement. Companies like Stripe, Webflow, and Shopify are making it easier to create online businesses. And companies like Airtable, Bubble, and Glide are making it possible for ordinary people to build powerful experiences on top of their own hypertext hacks.

But the foundation is still lacking. Hypertext itself hasn’t changed that much in the past three decades. It’s still, by default, pretty weak: it’s meant to create links between pages, not links to real-world actions.

I believe there’s a stage after “Low-Code”, a kind of hypertext 2.0. Maybe it comes with virtual reality, or cryptocurrency — or maybe it’s born when someone creates a new type of web browser. I don’t know. But, when it comes, it’s going to let anyone have the power to reshape the world with a good ol’ hyperlink.

Turn Your Static Website Into a Web App in Minutes With Remake, An Open Source Framework

David Miranda — Thu, 23 Jul 2020 15:27:17 +0000

Introducing Remake

If you've developed products before, you know there are two huge traps you can get stuck in because building web apps the traditional way is so damn hard:

Do a ton of research, come up with ideas, but never actually build anything. You never feel quite ready to commit because you’re not sure it’s “the right idea”.
Start building a really small piece of a really big idea, hoping that when you finally release the entire product years from now, it will “change everything overnight”, but never feel ready to show it to the world because “it’s not quite done yet”.

Remake solves this predicament by pulling it out at the root: it makes building an app so damn easy that all your reasons for not shipping it disappear.

Remake lets you turn static HTML into an interactive web app super quickly

Remake is a new type of framework whose goal is to make building web apps feel more like doing a quick sketch and less like painting a masterpiece.

What if you could use regular HTML to build a dynamic, editable website in about an hour? Well, we’ve got news for you — Remake makes this a reality.

Remake wants to help you, above all else: Find product/market fit by launching early and often.

Our goal is to speed up this process:

Get a working product into people's hands (Remake)
Get the feedback you need
Improve your product until it’s valuable to your users (Remake)

So, what is Remake, really?

Well, have you ever created a really nice design and wished people could just start using it? Remake lets you do that. Remake provides a simplified structure for what a web app can be, allowing you to take big shortcuts and speed up your workflow.

Remake works by redefining what HTML can do. It transforms HTML into a language that's purpose-built for making interactive websites. Simply put, Remake makes it possible to build a web app entirely in your front-end code.

With Remake, you can transform an HTML + CSS template into a fully-functional web app in minutes.

Add a few attributes to your HTML to create a working web app

Remake assumes that most of your app’s data will be:

Displayed directly on the page (as text, CSS styles, images, or uploaded files)
Will be editable by the page's owner — and only by them

Remake features powerful, built-in components that will allow your users to create, edit, and delete data from the page, while also creating a direct link between your HTML’s state and your back-end state so it can keep them in sync.

In most apps, HTML is already used for organizing and displaying data. The only thing it’s missing (before it can be used for building dynamic web applications) is the ability to save data in a separate location so the page can be re-rendered later.

A Language for Building Web Apps

Remake adds what's missing from HTML to transform it into a simple, declarative, and powerful language for building web apps.

So, now you can:

Use HTML attributes to attach data to the page
Sync that data to your back-end automatically
Use the structure of the data on the front-end in your back-end

And your users will be happy with your Remake web app as well!

It comes, out-of-the-box, with components for easily editing data
It has API endpoints that it calls automatically for you (for saving/creating/editing/deleting data)
It even supports user accounts and file-based routing so you can just focus on building something that works!

Build a Photo Blog in Only a Few Minutes!

With all of these powerful features, it only takes a few minutes to create a delightfully simple web app out of a few HTML + CSS files. With Remake, you can get back to shipping and everything else will be taken care of for you!

Create a photo blog web app in Remake in 20 lines of HTML

Remake is ready for your big idea. What do you want to make today?

"Intro to Remake (Part 2)" is coming soon. Sign up to hear about it!

How 3 Product Hunt UX Bugs Derailed My Product Launch

David Miranda — Sun, 19 Jan 2020 17:05:17 +0000

Let me begin by saying I love Product Hunt.

There's nothing else like it. Hacker News is too harsh. Reddit discourages self-promotion in 90% of its subreddits. Indie Hackers has too much self-promotion.

In all this noise, Product Hunt is an oasis of pure, early-startup excitement about, well, products — and the people who build them.

As an entrepreneur and solo founder, nothing appeals to me more than a community site designed around building new ideas, showing them off to the world, and putting them in people's hands.

It's a wonderful corner of the internet that I enjoy visiting daily.

An example of Product Hunt's supportive ethos from the founder

Launching my first product by accident

If you want to skip to the end, where I summarize Product Hunt's UX bugs and tell you how to avoid them, click here.

My first serious attempt at building a product for other people was Artisfy, a marketplace for hiring freelance illustrators for 1 hour at a time.

After spending 3 months designing every page in Sketch, 5 months building out the front-end code, and 6 months implementing a backend with Meteor, someone named Nate posted Artisfy to Product Hunt without telling me.

It was one of the best surprises I've ever received.

At 10am, on November 29, 2016 — 3 days after my birthday — I realized I was getting sign ups from real, actual freelance artists and users. By 10:15am, I realized where the traffic was coming from. Imagine my surprise when I realized Artisfy was featured in the #2 spot on the front page of my favorite website.

I was ecstatic.

Launching my second product on purpose (and the #1 UX bug)

After the success of Artisfy's surprise launch, I started talking with my new users. I emailed them, did lots of phone calls and video calls, went to meet them at coffee shops all around Boston and Cambridge, trying to learn what they wanted from Artisfy.

It didn't take long to realize most of them didn't need a new marketplace website. There were thousands of those already and many of the freelancers I talked to were looking to move off of them as soon as possible and recruit their own clients. Gradually, it sunk in for me: freelance illustrators needed a home for their professional services.

So, I set off to work on a brand new product, in the early days of 2017: RequestCreative.

This was a really, really exciting time for me. I was working out of a warm and lively co-working space and I got to focus on building RequestCreative every single day. I felt very lucky.

And, I had a plan for getting some early traction: Product Hunt Ship.

Product Hunt Ship has _ 2 _ big features.

The ability to schedule your product post
Promotion of your product on the Product Hunt home page!!!

If you can't tell, the second feature is, by far, the more exciting one 😆

You see, Product Hunt gets about 5 million visits per month (according to SimilarWeb). So, even if you're only featured 1% of the time (and I think it's more than that), that's a total of 5,000 people per month seeing your product.

That's an incredible value, especially since you know this audience is 1) interested in early-stage products and 2) might subscribe with just the click of the button to hear more about your startup in the future.

So, of course, I signed up right away and

Set up a Ship page
Uploaded my logo and media
Double checked to make sure everything looked right

Then I waited...

And over the course of the next three weeks, 2 subscribers trickled in.

They were both people I knew. 😫

It turns out, I had missed a toggle button that was buried deep in the Product Hunt Ship interface: "Promote on Product Hunt", which was off by default.

This very important toggle wasn't mentioned on the Product Hunt home page after I logged in, nor on my personal profile page — nor on my product's Edit Post page.
It also wasn't mentioned on the Product Hunt Ship Dashboard page.
It was buried, at the bottom of the sidebar, on the product's Upcoming page about 2/3 of the way down

That's quite a lot of burying for a feature that most users aren't even aware they should be looking for. I personally assumed that — since it was, by far, the most valuable feature of Product Hunt Ship — it would be turned on by default.

Where is the toggle? Not anywhere obvious.

This is currently the #1 UX bug on Product Hunt Ship and it ruined my second product launch.

During the launch day, when I didn't know about this little, secret toggle that unlocks 90% of the value of Product Hunt Ship, I was still blaming myself for not being able to get more subscribers.

I thought:

Maybe my copywriting is off

Maybe people just aren't interested in RequestCreative's promise

Maybe there was some secret algorithm that Product Hunt used to determine who was featured in the Upcoming box and I just wasn't chosen...

To be fair, Product Hunt Ship did send me one email with a mention of the "Promote on Product Hunt" toggle.

Can you find it?

However, their mention of it was in the second (not the first) onboarding email, hidden way below the fold on mobile devices. To find it, you had to read through a bunch of other (mostly useless) copy and scroll past a big, centered image.

No one has time for that.

And this was the only time in the onboarding they called it out.

I ended up spending $79 on Ship (and a month prepping for the launch) for almost no value — all because I missed this single sentence.

How to fix this UX bug

I think the solution to this UX bug is simple:

The first email Ship subscribers receive should have the subject line: "Your Product is Not Being Promoted Yet". That would pretty much do it. If you really want to be nice about it, maybe send them a followup 7 days later with the same subject line.
Then, on the user's list of upcoming products, in bold, red letters, it should probably say: this product is "Not being promoted yet"
Finally, on your Ship dashboard, at the top of the page, above the completely useless graph that was stuck at 2 users during my entire pre-launch, and highlighted in a bright red background, maybe say something like: "Do you want to enable promotion on Product Hunt? Yes or No"

Or, of course, they could just turn on promoting products by default , since it's literally the #1 reason anyone signs up for Ship and it's absolutely zany to charge for value you're not providing.

My first product's (failed) launch

If you're curious about how RequestCreative did on launch day... I won't lie and tell you I wasn't disappointed.

It hung out, just off of the front page, all day, right under the "Show More" button.

It was a little heart breaking.

My second product's tumultuous & amazing non-launch (and UX bugs #2 and #3)

After RequestCreative didn't land with a splash, I was a bit disheartened. I truly thought I had created something useful and amazing — something the Product Hunt community would love.

When it didn't do well, it was hard to keep working on it, even thought it's something I had invested a year of my life into.

For anyone struggling with this right now — the anticipation or reality of a "failed" launch — I'd strongly recommend watching this excellent video by YC Startup School:

"Please don't fall in love with your MVP. It's just step 1 in a journey."

So, anyways, as a way of recovering, I focused on something fun. I started tinkering around with the code behind RequestCreative and slowly extracting it into a web framework.

At first, I told myself it was just for fun. But then I was making notes and taping them to my wall — and drawing diagrams — and seeing if what I had on my hands was truly as groundbreaking as it seemed.

This, eventually, after a year of hard work, became Remake.

Which, kind of, sort of, launched a few weeks ago.

You see, despite visiting Product Hunt nearly every day, I'm still not an expert at it. And, it turns out, I unintentionally sabotaged my launch day with the stupidest mistake possible.

Delaying the launch

On November 11th, I made the decision to delay Remake's launch by 2 days, from 11/20 to 11/22.

My promo video wasn't finished yet, I had on a couple pages of documentation done, and I the website was only 50% done.

Then on November 18th, with the pressure of a quickly approaching launch day mounting again, and still no website ready yet...

I rescheduled again.

To the past... oops 🤪

Like any truly visionary founder, I moved up my MVP launch date to be as early as possible: November 5th — 2 weeks in the past.

🙃

And the thing that surprised me the most: Product Hunt Support simply responded with, "Sure thing that's changed for you now!"

The next morning, I checked on it and realized my unbelievable mistake and the Product Hunt staff quickly rectified the situation.

Remake was now back to being scheduled for the future — December 5th — and I was going to be ready!

(However, this simple rescheduling-to-the-past mistake would soon come back to haunt me...)

UX Mistake #2

Before we get to the true comedy of errors of this story, this is where Product Hunt's UX mistake #2 comes in.

The only reason I needed to talk to a human to reschedule my post (instead of doing it myself) was because their scheduler only allows you to select a date a few weeks out.

And, although it gives the mistaken impression that you can keep pushing it further out every couple of weeks, indefinitely — eventually you reach a hard limit.

So, the simple solution here would be to allow people to schedule their product whenever they want to.

Ideally, only in the future. 😆

You might wonder: why even schedule your product at all if it turns out to be this complicated — having to reach out to customer support every couple weeks?

Well, it turns out, if you choose not schedule your product's launch, then _ anyone else can launch your product for you —_ before you're ready 😳 — even if you have an upcoming product and are paying for Product Hunt Ship.

Launching early, this time around, would've been a disaster — unlike with Artisfy.

You see, at this time, I still thought of Product Hunt as a great source of interested early users and developers and I was really looking forward to knocking it out of the park with a beautiful startup website.

If someone launched my product early, the website would've been the early, very rough, barely coherent documentation site — which provided only a single demo, no email sign up forms, and no substantial information about how to use Remake.

It probably wouldn't have done well — and I wouldn't have been able to launch it again on my own, since it was launched already.

When I spent 3 months of time and energy gearing up for a big Product Hunt release, it simply wasn't worth it to launch early.

The day before launch day

Remember when I mistakenly scheduled my post for November 5th — two weeks in the past?

Well, apparently that caused some major issues with Product Hunt's backend and really came back to bite me the day before launch.

I was in the middle of updating the launch website, when I remembered to check in on my Product Hunt post to make sure everything looked good.

That's when I noticed something really bad:

Remake had suddenly reverted to being posted a month ago. 😣

I reached out to support right away.

As usual, they responded in under an hour and rescheduled the post for December 5th — the following day.

Then, while continuing to prepare my post for launch day — adding some images, refining the copy and headlines — I noticed it happened... _ again. _ 😳

At this point, it was the evening before the launch — just a few hours out.

I started panicking:

What if I was doing something wrong? What if it wasn't a database error on Product Hunt's part, but I was responsible for launching it by mistake?
Was there a secret toggle (like Ship) somewhere that I wasn't seeing?
Was the support staff going to think I was trying to cheat the system somehow — and prevent me from launching altogether!?

I quickly looked around on the Edit Post page, looking for anything that might have caused the scheduled date to be canceled and cause my product to launch right away.

And that's when I saw it: a simple little magic toggle that I had never truly understood, but had occasionally toggled when I didn't know what else to do.

I know, I know...you really wouldn't think I design web apps for a living... 🤪 The #1 rule for users of software should be, "don't toggle a magic setting you don't understand."

The two options:

With no further explanation.

I assumed, in my moment of (slight) panic, that these options referred to the status of my product post, _ not the status of my startup. _

You see, a "pre-launch startup" is a technical term in Silicon Valley. It means:

Your product isn't ready yet.
It's not available.
It's pre-launch.

As a Boston native, I don't hear it as much, except when I'm watching YC videos.

So, (somewhat my fault here...) it simply didn't register as having anything to do with the status of my product/startup.

I especially didn't think it would be something that would completely decimate my launch.

So, I set the Status to Pre-launch , contacted customer support to reschedule the post, and promptly forgot about the magic little toggle.

"Please don't make any further changes"

This is about the time someone on the Product Hunt staff told me to stop editing my post, because: "when you update the post, it stops it from being scheduled."

😳

Huh?

Well, um.... okay, I guess. 😐

That made no sense to me, but I figured it was probably because of the scheduling-to-the-past thing from earlier (which must have really caused some hard-to-undo database flag to be set).

I told the marketing freelancer I was working with to not touch the post either — it was completely hands-off until launch time.

We both gently stepped away from the keyboard, hoping and expecting a perfectly normal, relatively successful Product Hunt launch.

I sent out the launch emails and went to bed.

Launch email for RemakeTheWeb.com

The day of the launch

I woke up on the morning of the launch and checked on the Product Hunt post. It had gotten 7 upvotes already — more than a lot of the other posts, but fewer than some.

It hadn't made it to the home page yet...

But I was still hopeful.

I went for a walk, recorded a quick launch day video for people interested in the project, and went back inside to start my 9 hour launch live stream 😁

I answered questions and emails, got some serious help from @levelsio on a Twitter post that went viral, posted a couple launch posts to Reddit and Designer News — and checked on Product Hunt about 3 times an hour.

For the whole day, I couldn't shake the feeling that Remake should've reached the front page with the amount of votes it was getting.

Then I got a couple of messages from Product Hunt users that Remake wasn't showing up anywhere on Product Hunt — not even when they searched for it. They said they had to go to the "New" tab and scroll forever just to find it.

I started worrying that maybe something had gone really wrong.

Maybe I really had messed up Product Hunt's database with my rescheduling... Or annoyed the staff enough with my requests for them to shadow ban me from the home page...

To be honest, I had no idea what was happening.

I reached out to customer support, once again, towards the end of the day — after not making it onto the home page despite getting more upvotes than 7 of the other products featured there.

I don't understand why my page failed to reach the front page — even under the Show More button. It launched around the same time as a lot of the products at the bottom and received more upvotes than some, but it never made it to the front page.

Did something malfunction with my post again?

Then I got a little cynical: was it an editorial decision? Did the staff prevent my post from hitting the front page because they thought it wasn't good enough?

I scoured Product Hunt's FAQ for answers.

At the very bottom of the FAQ articles in the "Posting" category, I came across a certain article title — that, when I read it, instantly made me realize my big mistake. 🤦‍♂️

I suddenly remembered back to that toggle on the Edit Post page.

I opened the FAQ article to read it.

Here's what it said:

We encourage people to submit launched products that are available to play with immediately; however, the occasional crowdfunded or pre-launch submission is acceptable if it provides thorough information about the product (e.g. clear video with a product feature walkthrough) and proof that it's not vaporware. That said, we may remove pre-launch submissions and recommend founders to wait until their product has launched before submitting.

link

I didn't want to admit it to myself, but I had single-handedly sabotaged my own product launch and been responsible for shadow-banning myself from the Product Hunt home page.

I reached out to customer support one more time.

Indeed, that was it.

They reached out to me shortly after, with a link to the article I had just read.

UX mistake #3 and how to fix it

I'm sure a lot of people who launch on Product Hunt know what Pre-launch means and they, also, might understand that it impacts their eligibility to reach the home page.

But, also, maybe they don't.

It would be very, very polite of Product Hunt to just tell you, on the Edit Post page, exactly what Pre-launch means — so more people like me don't sabotage months of work over a misunderstanding.

Or even just: "Pre-launch means product is not available for use yet."

Why I'm writing this post

So, you might be wondering: what happened to Remake?

Well, actually, thanks to a launch tweet that @levelsio helped me write and share, the launch was actually a big success!

David Miranda

@panphora

I built a framework called 🧙‍♂️Remake that lets you build an interactive website, using only HTML:

🤖 Build and design an app
🧘‍♀️ User accounts
🦙 Zero config
🏹 Built-in CRUD features

👇remaketheweb.com

17:22 PM - 05 Dec 2019

33 175

Remake also received a lot of interest on Reddit and Designer News!

All this, despite not receiving any traffic from Product Hunt. Since my product wasn't featured at all or even available in search, Remake ended up sending hundreds of visitors to Product Hunt, but didn't really receive any back.

I'm hoping Product Hunt might consider giving me a redo, but for now I'm happy to just share this, so someone else with a big idea might avoid my mistakes.

For now, Remake is still marked as pre-launch, even though the product, on launch day, was (and has been for months) functional and ready to use!

Apparently, this little dot means you're still pre-launch

I only learned what this little dot of invisibility meant on December 6th, after it was too late. If I only I had hovered over it... 👻

So, without further ado:

A Quick TLDR Summary of Product Hunt's UX Mistakes and How to Avoid Them For Your Own Launch

If you sign up for Product Hunt Ship, no matter what, find the magic "Promote on Product Hunt" toggle and turn it on:

It will help your launch out so, so much and get you a lot of early email subscribers! It's totally worth (even double) the current cost of Ship_._

Hint: It's on your upcoming page, in the sidebar, about halfway down, under a few other options you probably don't care about.

If you decide to reschedule your launch at any point, check with a friend or coworker first to make sure the launch date you chose is in the future 😜, because otherwise, Product Hunt might schedule it in the past for you — mark it is as already launched — and that could cause a lot of unexpected, totally weird issues for you down the line.

🤷‍♂️

Seriously, though: I'd recommend claiming your product's URL by scheduling a post and then ask customer support to schedule your launch way in the future.

This way, you'll have plenty of breathing room, and you won't have to deal with the hassle of reaching out to Customer Support every week or two to push push back your launch into the future.

And you can just launch when you want, with no worries or mishaps.

Don't touch the Status dropdown on your Edit Post page. Don't ask what it does or what it means. Just don't touch it.

Thanks for reading :)

Reach out if you want any more tips on Product Hunt launches — I'm (very slowly) becoming competent at using it. 😆

Psst! Take a look at Remake: A faster way to build web apps.

Open Question: How can I upload files to S3 from Node.js, while having a progress bar and the ability to resize the image?

David Miranda — Wed, 26 Dec 2018 05:13:35 +0000

Hello Dev.to,

This is an open request for help/suggestions. I'm new to contributing to this community, but a long-time fan.

I have a problem that I'm hoping you can help with. I'd post this on Stack Overflow, but I'm hoping a conversation here can be more open-ended than it would be there.

I'm currently building a web app in which image uploading is a core component. I have uploading working and implementing, with a progress bar to show the user the status of the upload. I also have the ability to crop/resize the image after it's uploaded. I'm currently doing this all with the multer npm package.

However, whenever I deploy my server, the PaaS I'm using wipes out all the uploaded files because the new deploy replaces the old one. So, I needed to switch to uploading to a 3rd party service like S3 (or start hosting my web app on Digital Ocean).

Recently, I got uploads to S3 working with multer by using the companion package, multer-s3. However, with multer-s3, I lose the ability to track the progress of the upload. If you look up the httpUploadProgress event that's fired by the AWS SDK, you'll quickly find that the event is only fired at the end of an upload -- not multiple times a second as you might expect from an AJAX progress event.

So, if I want to keep support file uploading and still have a progress bar, here are my options:

Use a 3rd party service like Cloudinary or Transloadit or Uploadcare or Imgix, etc., etc.
Upload images directly to S3 using a Presigned Url

Or.... 3. Get rid of the progress bar altogether.

For the life of me, I can't understand why this is such a hard problem. I feel like there must be a simple solution I'm just not aware of.

To quickly go through the reasons I don't like my current options:

A 3rd party service locks me into their API. Some of these services require jQuery and/or other large front-end libraries in order to upload directly to them (I'd prefer just an endpoint). And, if I choose to send the file directly from my server to avoid these extra client-side dependencies, it's not clear from their docs if most of these services would even return a progress event... However, in the end, the main problem with these services is cost. I don't ever want to pay $20 - $50 per month to handle file uploads if I can do it for $1-$2 on my own (although, at this point, it might be worth it).
The second option, uploading directly to S3 from the client using a Presigned URL, would be great in the near term, as I don't really want to modify the images just yet. However, in the near future, I could definitely see converting some of the images to WebP for browsers that support that image format -- or trimming some fat off the larger 2-20MB images.

And, as for the option of removing the progress bar... I think it's a huge usability enhancement to have one! As a user, it's really nice to know when your work is saved and how long it will take. I guess I could just show an infinite loading indicator, but then I worry about the people on a slow connection who might be sitting there with no indication when the stupid indicator is going to stop spinning... just waiting, and waiting...

So, I'm really stuck here. On the one hand, I feel like image uploading with a progress bar (and the ability to modify the image on the back-end after) should be a solved and simple problem. While, on the other hand, I'm strongly considering just biting the bullet and going with something like Cloudinary, even though it will probably double the size of my client-side JavaScript bundle (something I'd really love to avoid).

So... Are there any services or packages you know of that I'm missing? Is there anything you know of that will let me upload files in Node.js to an 3rd party storage service like S3, while showing a progress bar to the user, while not adding lots of dependencies to my client-side JS, while giving me the ability to optimize/crop/convert images after they've been uploaded?

Now that I think about it... maybe this IS a lot to ask... heh. And, to think, I was incredulous towards a back-end developer 10 years ago when he told me this was a hard problem... 🙈

Any open source solution would be a huge plus, but an upload service that costs $10/month would be great too.

This is an open discussion and all suggestions are welcome! 😬😁☃️ Happy Holidays!