WebConverter Experiment Post-Mortem

5 minute read.

I work with We­bAssem­bly ev­ery day for Won­der­land En­gine. This means I built a lot of de­vel­op­ment in­fra­struc­ture around it, mak­ing it easy to start new WASM based projects. This is the post mortem of a project that failed, but at least had some mer­it to its mo­ti­va­tion that I want to doc­u­ment here.

One of my weak­ness­es is that I love start­ing new projects. Not be­cause I get bored of the pre­vi­ous, but be­cause I come up with more and more ideas I find worth pur­su­ing.

A sheer end­less source of op­por­tu­ni­ty, for ex­am­ple, is the trend of the web to con­verge to na­tive per­for­mance with new APIs like We­bAssem­bly and We­bG­PU.

This means that many ap­pli­ca­tions that can run on the web, will run on the web and dom­i­nate over their na­tive coun­ter­parts, be­cause of the con­ve­nience of ac­cess, su­pe­ri­or speed of de­vel­op­ment and rapid per­mis­sion­less de­ploy­ment.

Cost of Bandwidth

I re­alised that on­line con­vert­er tools usu­al­ly con­vert files by up­load­ing them to a serv­er, where they wait in a queue to be con­vert­ed, cached and sent back to the us­er on down­load.

Why?

To­day, with We­bAssem­bly, you can many file con­ver­sions ef­fi­cient­ly enough di­rect­ly on the web page, client side. That saves a lot of mon­ey on the serv­er in­fra­struc­ture side.

I fig­ured out, that there’s an en­vi­ron­men­tal cost to band­width as well, and since cli­mate change is such an im­por­tant top­ic nowa­days, I was fixed on try­ing to change the en­tire on­line con­vert­er in­dus­try for the bet­ter… in a week­end.

We­b­Con­vert­er.app would con­vert ba­sic im­age files and count the kilo­grams of CO2 that were saved by us­ing the con­vert­er over one that does up- and down­loads.

Zero Operating Cost

Us­ing We­bAssem­bly, I didn’t need servers to do the con­ver­sion. The web app could be a su­per light weight stat­ic web­site that can even be served on Giltab Pages, which is free! It even has Let’s En­crypt in­te­grat­ed for free SSL cer­tifi­cates.

My to­tal op­er­at­ing cost would there­fore amount to ze­ro. (I am pay­ing for the do­main, but that is fair­ly neglible.)

Competition

On­line con­vert­er tools are a hy­per­com­pet­i­tive over­crowd­ed mar­ket. They com­pete through SEO or ads on search and need to make enough via ads on their page to be able to jus­ti­fy the us­er ac­qui­si­tion cost. Of­ten that rev­enue is aug­ment­ed by some pre­mi­um sub­scrip­tion of­fer.

I had one huge ad­van­tage and one huge dis­ad­van­tage: I have 0 cost of serv­ing a us­er (no band­width or serv­er-side com­pute cost), but way less for­mats I my con­vert­er could con­vert.

Ad­di­tion­al­ly, We­b­Con­vert­er.app is an in­stal­lable web app (PWA), which could yield high­er re­ten­tion rates, in­creas­ing ARPU (av­er­age rev­enue per us­er) with stat­ic CAC (cus­tomer ac­qui­si­tion cost).

Re­duc­ing the car­bon foot­print could be a pow­er­ful mar­ket­ing ad­van­tage.

In the­o­ry this means that I can pay more for us­er ac­qui­si­tion on Google Ads as my mar­gins are high­er. But in prac­tice, Google Ad­sense did not ac­cept my page due to lack of “qual­i­ty con­tent”, so un­for­tu­nal­ly, the ex­per­i­ment end­ed here.

The End?

I have ef­fec­tive­ly found an in­ter­est­ing busi­ness that I could pull off through my spe­cif­ic tech­ni­cal back­ground, which in hind­sight most­ly acts as a small ego boost and was a fun ex­cer­cise. It re­quires more than a week­end to ac­tu­al­ly set in mo­tion and is now in the realm of oth­er skillsets.

I don’t be­lieve I’ll spend more time on this project, but feel free to drop a mes­sage, if you be­lieve that you can make some­thing out of this tech­ni­cal base with your writ­ing, SEO or mar­ket­ing skills.

Takeaway

Tech­no­log­i­cal ef­fi­cien­ty is more eco­log­i­cal and can be an eco­nom­i­cal ad­van­tage.