Why we threw away 3 years of work to create something better

Erik Gonzalez

Co-Founder and Head of Marketing @ KwesForms.

Before we launched KwesForms publicly in March 2019, we worked super hard for two years building our product and another year refining it. Yet, we decided to throw it all away and start over again.

Throwing away computer meme

Why you may ask? well, needless to say, we learned a lot of lessons from our customers and it ultimately, drove us to build an even better product.

Our product didn't always play nice

We always wanted our form script to easily integrate into any web stack. Looking back now, V1 was OK at this, but not great. (Who wants to be only OK?)

We built V1 using Vue.js since it allowed us to quickly build the features we dreamed of. Unfortunately, as our users started adopting our product, we realized it wasn't as platform-agnostic as we hoped. Vue.js just kept getting in the way of their experience.

This made us realize we needed more than just an update; we needed a complete overhaul. (Back to the drawing board...). ๐Ÿ˜ž

๐ŸŽ‰ Teaching our product some manners ๐ŸŽ‰

We decided to start over and rebuild it from scratch by completely rewriting it in pure vanilla JavaScript. It finally plays nice!

It now has the foundation to truly integrate seamlessly into any web stack. Whether it's a static site generator, CMS platform, SPA, page builder, or development framework, it just works.

The beauty of this is that dev teams no longer have to switch their form tool because the next project is on a different stack. This increases efficiency and lowers production cost on projects for web agencies.

File size was too large

When we built V1, we had no expectations of what community will take the lead in adopting our product. (Or if anyone will adopt it at all). We just needed to launch and see what happens.

As more users started to use our form service, we began noticing an interesting trend. JAMstack sites! The JAMstack community quickly adopted our tool and it was a match made in heaven.

Only one problem, our form script was too large in size. V1 was 300KB! Ouch. JAMstack sites are meant to be lightweight, and ultra fast, yet our script was slow as molasses.

Even with this downside, many users sacrificed a bit of load time just to use our form service. This said a lot!

๐ŸŽ‰ Honey, I shrunk the file! (Sorry) ๐ŸŽ‰

Rewriting our script in vanilla JS reduced the file size by 93%! It went from 300KB to about 20KB!

This tiny file size makes loading the script incredibly fast!

The script itself was also redesigned to FEEL faster in the way it handles certain tasks. For example, frontend validation now responds quicker to a users input. The response feels immediate to the user which can lead to a better user experience which leads to more form submissions.

V2 vs V1 Speed TestV2 is on the left side, you can see the error message dissapearing first compared to V1 on the right side.

Form styling needed to be easier

Many developers choose to use drag-and-drop form builders. The problem with that is, it requires a lot of extra code gymnastics to get the form looking as cool as they want. (Not built for developers smh).

Not the best workflow if you ask me, and that's why we wanted to make styling your form a very simple process.

Although V1 was easier to style than those drag and drop alternatives, it still required a few extra steps that we just couldnโ€™t avoid at the time.

To make the form script work properly across many different platforms, we had to wrap the form inputs with extra code. This gave us more control but sacrificed the users experience. (It also wasn't very transparent of us.)

We knew it could still be better. We owed it to our customers!

๐ŸŽ‰ Styling your form is now a breeze ๐ŸŽ‰

With V2, you can style forms 100% your way. It will no longer add any extra code or wrappers to your HTML elements. This is how we dreamed it from the beginning! Your HTML will remain completely untouched by us.

V2 makes styling and integrating a complete form service into your website the easiest solution available! (It might also be.. the most enjoyable ๐Ÿ˜Œ)

Form syntax got in the way

When we developed the syntax for our script we worked backwards. We told ourselves โ€œwouldnโ€™t it be cool if we can just write it like this?โ€ and then we willed it into existence!

For example, if a user needs to add a datepicker to a form wouldnโ€™t it be cool if they just wrote it like this?

<input type="datepicker">

Voila! Instant datepicker in one line of code.

This solution is the simplest for most users, but it presented a problem for others...

As great minds think alike, there were other frameworks that had the same type of syntax which caused a conflict with our script. Other users simply needed to make sure the syntax was W3C valid, and our special syntax obviously wasnโ€™t.

๐ŸŽ‰ Form syntax for the masses ๐ŸŽ‰

Our script now offers both a simple pretty syntax, and a W3C syntax option for W3C validation and any framework conflicts.

Language support was good, not great

V1 was the first and only service offering form validation messages in 73 languages. No one else even comes close to that.

This has resulted in developers from all over the world adopting our product just for the language feature. Despite all this, we still had a lot of room for improvement.

Validation errors were the only things written in multiple languages. All other messages were only displayed in English.

We believe developers and their customers should have a great and easy form experience no matter what language they speak.

๐ŸŽ‰ Language support is great, not good ๐ŸŽ‰

On V2 we've completely overhauled our messaging system to support our non-English speaking users! Every feedback message and every error message are now displayed in your desired language.

Previously, the language was set on the form settings page. Now the form language can be set using โ€œlangโ€ or โ€œdata-kw-langโ€ attribute on your form tag.

<form ...<lang="es">

Last but not least, all languages can now be accessed on any plan. Yes, even the free one.

Developers still needed more control

Our product provided customers with a lot of control to build whatever form they needed. But yet, it was still not enough for some.

Although we provided awesome solutions for form validation, spam protection, email management etc. We still had a lot of users approach us with very specific form needs that we just couldn't satisfy.... Yet.

We needed to provide a simple way for users to add their own custom functionality when needed. It's definitely not easy providing "one size fits all" solutions that actually work, but then again, greatness is never easy ๐Ÿ˜Œ.

๐ŸŽ‰ Taking control with โ€œForm Eventsโ€ ๐ŸŽ‰

We now provide custom events for users to hook onto. Why is this so special? Well, users can now add custom functionality when a form is submitted, or when a validation error occurs.

We once had a user ask if he can hide his form after it was submitted so he can show a custom message and animation ๐Ÿคท๐Ÿปโ€โ™‚โ€. Basically, it was impossible with V1, but easy to do with V2!

Simply put, you can make your form do whatever you dream up ๐Ÿคฏ.

๐ŸŽ‰ Taking control with โ€œCustom Validation Rulesโ€ ๐ŸŽ‰

Other users also needed to add their own custom validation rules. For example, we once had a user that didn't want to accept messages from any Gmail email addresses.

He wanted to display an error to the user if a Gmail account was detected. We obviously can't just write an endless number of rules for every single unique situation. We needed a more flexible option...

We present to you... (drum roll) "Custom Form Validation Rules" ๐ŸŽ‰. This may sound boring but hear me out! We now allow our users to write their own logic for custom rules that behave exactly like our own native rules. Still sound boring? Alright, well sorry but it's a big deal trust me ๐Ÿ™ƒ.

Needless to say, the user mentioned above was able to easily implement his custom Gmail rule. (Yay).

Learn from your mistakes

The thought of throwing away 3 years of work may sound scary to many. Itโ€™s really not scary though. Starting over is scary lol. But sometimes (as it was in our case), it's absolutely necessary.

Our first version allowed us to get to know the market and to develop great relationships with our customers. This of course allowed us to hear them out and to learn what our flaws were. The difficult part comes afterward, actually listening.

We realized that V1 just wasn't good enough and couldn't be scaled to the heights we needed. It served its purpose but it was time to move on.

There's a lot to learn from your first time... (first time building products that is). You get to know your audience, you see what they like, what works, and what doesn't. And sometimes, you may just need to start over, and that's ok! It's ok to make mistakes, the key is to learn from them. It may just be what you need to take your product toโ€ฆ the next level (echo for emphasisโ€ฆ)

Help us out!

If this article has helped you in any way or you just seem to like us, share it and tell us your thoughts below! If you do, I'll be your friend, I promise.