The first version of Picly, an image server that applies transformations on the fly through the URL itself, has been available in beta 1 for a few weeks now. It’s been eight months since its first prototype. Although we’ll release the commercial version in a few weeks, we’ve started “communicating with the market” about this new product, because if you launch with too many features, you’re launching too late…
There’s a huge amount of work behind this project, involving the entire development team at Solid Stack. It’s built with Node.js, uses Redis as its database, and required a great deal of testing before we released this first version.
Did I say “a huge amount of work”?
People often overlook the fact that behind a simple commercial website—which already takes plenty of work in design, usability, calls to action, and so on—there’s an entire infrastructure supporting all the business processes.
People without much technical experience, and even many developers who set out to test an idea, don’t realize how much effort it takes to coordinate, develop, and, above all, maintain the software and hardware infrastructure needed to sell a product. Over time, that product will have different versions and be offered through different commercial plans (free, professional, and enterprise).
I’m afraid it’s not as simple as publishing an attractive website and starting to make money from day one…
Just to release a first beta, we had to deploy and develop all of the following:
- A responsive website with an attractive, commercial design: www.picly.io.
- An easy-to-use, responsive web application for the registered users’ dashboard, published at account.picly.io.
- A REST API to support the above, currently published at
api.picly.io. - And, of course, the product itself, downloadable and ready to run on a local machine.
To build all of that, we had to:
- Develop the product to a quality level suitable for a beta 1 release (with tests, manual checks, exploratory testing, and so on). That alone was a challenge: it’s a relatively complex technical solution intended to be less expensive and much more flexible than services such as Cloudinary.
- Put considerable effort into configuration management and the release “build” process: selecting the assets to publish, obfuscating the more sensitive parts of the code, minifying libraries and CSS for the different websites and Picly’s control panel, and so on.
- Develop an in-depth understanding of the technologies and libraries we used: Node.js, Redis, Bootstrap, distributed architecture design, GraphicsMagick, OpenCV, and more.
- Set up an “inversion of control” mechanism for integrating Picly plugins, which perform the on-the-fly transformations.
- Hold countless meetings to consolidate what we’d implemented and define the next steps.
- Integrate the payment gateway through Stripe.
- Integrate many other services, such as Google Analytics, Hotjar, and so on.
All of this seems overwhelming at first—and in reality, it is. What’s important, though, is to keep taking small, steady steps in a clear direction until the minimum functionality is ready to launch and introduce the new project to the market.
To me, the key to doing a good job on something that seems enormous is continuous refinement.
What comes next?
From this point on, the hard work continues, but in a different phase: we need to put business processes in place through well-defined, orderly procedures, such as:
- Regularly communicating with the market through news, tweets, and so on.
- Outreach campaigns, webinars, meetups, mailing lists, and direct contact with companies as potential customers.
- Ways to collect, organize, and analyze feedback.
- Support procedures.
- Internal security audits of all the infrastructure built to support Picly.
- Tracking sold licenses.
- Monitoring user activity.
- Procedures for releasing new updates, both for the websites and for the product itself.
- Defining vanity-free metrics to assess the impact of any communication to the market.
- And so on.
This is a tremendous amount of work, but when it’s well-defined and organized, it can be done with the discipline needed to succeed with a product like Picly.
We’ve put a lot of effort into keeping Picly’s design clean and clear, with simple modules backed by tests, clean code, and all the good practices needed to build a maintainable, evolving product. A lot of stories have come up along the way, and I’ll share them gradually: for example, why we haven’t used a framework such as Angular or React for the different web applications, why I made the design decision to use Redis as the database, and much more.
I’ll continue writing about all of this, both the technical side of Picly and the specific business processes we’re putting in place right now.
In any case, I encourage you to download the product and send us plenty of suggestions and feedback!