For the past year or so we have been working on building a new 1DayLater from the ground and I'm letting myself get excited about it; this blog post is clearly premature, but what the hey, I want to write a little about what we're doing.
The easiest changes to describe are our technologies, almost every choice made in the original system has been reviewed and (mostly) found wanting. We've really matured the software with this new version and myself as a programmer too; I'm growing ever more comfortable with the iterative development process to the point that I consider a bad day as NOT pushing a new release live.
A lot of this has come from building the NexGen software with Lucion Environmental (more on this another time) suffice to say that when you support a diverse and growing company you see the fruits of your labour almost instantly. If the person in the room next door has a bug and they see it fixed instantly there's gratitude aplenty!
I digress, here's some of the changes we've made on the new 1DayLater... and why
Version Control: Subversion > Git once you get over the initial learning curve, git has many advantages
Deployment: FTP > Git Hooks we can update the site with simply "git push" and all the right files will be in place
Hosting: Rackspace > Amazon Web Services an excellent developer community and lower price makes this logical
Database: MyISAM > InnoDB currently 1DayLater is non-relational, we now require a more logical relational structure
Markup: Handcoded > Twitter Bootstrap frankly, I can't afford to spend too much time pushing pixels - this makes it much quicker to knock up pages
Templating: Custom > Handlebars I wrote my own templating engine and it was very patchy, we picked the most popular and active engine for the new system
PDF Printing: wkhtmltopdf > PrinceXML once we go live we will (gulp) fork out the licence fee for a commercial printing program; after all this will be our new product
But if you prefer I can quickly explain what we're making:
Our Users can create Quotes to send to their clients
Quotes are made up of Line-Items with an estimate tally
Users can then Log their Activity against these Line-Items
They can then convert their Activity into Invoices to send to their clients
Tony the plasterer Quotes for a small Job
It is made up of these Line-Items
3 Days on site at £250 / day
1 Disposable tarpaulin at £30 (estimated)
1 Day of Van hire at £60
On site he logs his work against these activities, on the second day he notices his client has torn the tarpaulin so he gets another one and so logs two of that
He can then draw up an Invoice
The idea is that Tony does the MINIMUM amount of admin but gets access to some very valuable information and tools, ie:
Send Invoices and Quotes to his clients
Get notified when his clients view his Invoices and Quotes
Find the Quotes with outstanding work (ie money)
See which Invoices are overdue
Visualise his profitability
Furthermore he can inviate collaborators to log their activities against his Quotes (maybe he hires staff etc.)
Well, we've paid off the business loan, we're financially stable (profitable in fact) and are busy investing in the company. On the financial front we're pretty happy at the moment but (as all businesses should) we want to be very profitable and hire more staff for support and whatnot.
With the new product we spent a great deal of time pondering how to price the product and catch customers at each stage of the curve, this is what we thought:
When is the product valuable?
When the client sends an Invoice
we thought that the data, visuals, outstanding work etc were valuable, but that they're also so intangible that would be difficult to describe and sell
How much is an Invoice worth?
We decided that it couldn't impact on the value of the invoice but had to be a nice round number, a QUID seems decent. We'll review this soon enough
How can our users pay for it?
On a subscription (Monthly or Yearly)
Buy a set number of Invoices (Tokens)
Last time round the finances were second to the product, this time we've actually gone ahead and designed and implemented our payment pages first. Yup, before the product is even finished; we don't want bugfixes and whatnot getting in the way of our cashflow, after all if 1DayLater wasn't financially viable (for us) those bugfixes and improvements would be worthless as the service would eventually disappear.