Feedback: The pdf looks nice! I worry about parsers not getting things right
(and, er, me not getting things right for the parser, typos, mistakes etc.), so this scares me a little. Plus, the "5 invoices" is also "5 attempts", discouraging trial-and-error to get it right. It would be great if you could somehow address the developer problem, of asking for money, by closing the gap even more. It does help already, great if it could help more - that is, focus on what will help someone accomplish their task, not on the actual code or product, what it does, how it does it. Just changing the process or steps might help; or changing the copy on the website (the way it's presented).
e.g. If it formed a buffer between you and the customer (like a secretary), so you just state the straightforward, factual information (no stress!), as if talking to a friendly ally (who is on your side!), and then it takes care of the rest of it - including sending it. But if you went that route, there needs to be a way to check it. Sending incorrect invoices is also scary!
EDIT I don't mean the parser fails to parse in a technical sense, I mean it didn't do what you wanted/expected. It's pretty common (think: regex problems).
EDIT2 I was thinking that a markdown-like syntax might work well, because more familiar - but then I remembered that I often test my markdown to check it does what I think. Same issue.
Yea, I agree that making a solution to bridge the gap would be useful. Oooh! Great idea: if you took the data and automatically created a webpage that the person receiving the invoice could go to to pay the person for the amount, etc. and then put the link in the invoice would really help the seller get his money and it would be easier for the buyer to pay! win-win!
Thanks for the feedback. That was very useful insight.
5 invoices is not 5 attempts (parser errors not counted). It's 5 successfully created invoices, unless you make typos in the name, address, etc, then that's counted too. I'll have to make that clear on the pricing page.
If typos and other accidental errors end up being a problem, you could use a different email for proofing or demos. The proofing email wouldn't count against the 5 invoices, and would include a prominent watermark or something. Just a thought.
I wanted to chime in here to backup `flyingyeti's` point. If you slap a giant watermark on it (doesn't count as a hit against the free 5), then it encourages experimentation and interaction with the platform. I'd think you'd want this, as your users will likely discover errors, problems, and output that doesn't meet their expectations.
I like the general idea of making email a human api for web services.
Email based invoice generation service, markdown renderers, tweet/blog from email, post to forum etc. seem to fit into this category. Services like event/reservation booking can also be used from email if the service has a forgiving parser (like WolframAlpha) for the human input.
I agree. We've been thinking about email as an interface for a while now. It's the most accessible interface. And every once in a while there's a discussion on HN about this. So I guess this acts as proof of concept.
I highly recommend adding a privacy policy as soon as possible, so we know (among other things) exactly how you will use the information gathered. Will it be stored? Will you send us marketing emails? Will you sell our data? etc.
Perhaps you could also have a text submit page (form), and then allow people to download the generated pdf? (Allows people to try out anonymously)
Also, generating in some kind of editable format, may be a good idea. For any minor edits I want to do, on the generated invoice, or fix any errors in generation because of its interpretation of the text.
Quick tip that could be relevant for Indian businesses - Most of the invoice recipients insist on the invoice sent on the letterhead.
While asking for an image/banner to be used as letterhead could be too 'tedious'. How about letting the user attach company logo in the email & you process it as letterhead.
Company logo & name below it on the left, company address on the right. May be - make the background color gray to show it as letterhead.
This would not be a valid invoice in Sweden. Here, there needs to be a reference number, VAT registration number, information about interest rate if late payment, location of the board if the selling company is a limited company, and probably a few more things. I think the same applies for most EU countries. Can US invoices be this simple?
Looks handy. But I miss a field where I can specify payment information, such as bank account #s, paypal info, whatever. So it would probably be nice if I register as a "Business" with all my information and just send an Email to your service which specifies customer name/address + products sold + tax.
I love this idea and have also been thinking often of similar email-based solutions. Very cool, but here's some feedback anyways.
The main problem is inevitably the syntax. It very quickly becomes too complicated, and with email you have the additional problem that you don't get instant feedback on submission.
In your case, the syntax might be simple enough to not be an issue. However, for many people (me included), it would probably still be easier, less error-prone and quicker to use a web interface with instant feedback. And since the type of person using this service is likely to be quite fast and proficient, there's little advantage to your solution over a web-based interface.
I do think there's a way to add value for users like me, though. Three things I like about email could be leveraged (more):
1. I always have email open
2. I tend to use email for quick, short messages that have more permanence than chat.
3. I tend to use email to keep track of things. For example, I don't open my billing app (Billings OSX) to see if I already sent out an invoice, of if it's due. Instead, I just search in gmail to see if I sent out the invoice, and when.
What you could add to this project to make it worthwhile to me, and I suspect many others, is the idea of partial invoices. I would send an email with one or more items, and these would then be added as items to this 'account'. Finally, I can send out an invoice with the total items by logging into your web interface, or through email.
It would greatly benefit me to send an email with something like:
"50 mins, implement login system, clientname"
It would be vastly preferable to my current approach where I load up the application, navigate to the client, and add the item, or alternatively where i add this item to my task app.
I disagree. I thought it was a clever idea to ask people what they would pay for the service. It's a simple service, pricing it would be hard unless people tell them how much it's worth to them.
The question isn't. 'What do you think this service is worth?' - the question is 'How much would you be willing to pay for this?'.
The key difference being, I may like to use the service if it was $5 a month, but not if it was $50 a month - on the other hand someone else may do thousands of invoices and be happy to pay $100 a month.
The feedback he'll get will let him guage the size of the market, the prices people will be prepared to pay and allow him to offer a reasonable plan. Without this prior research he could over price or under price the product substantially.
If on the other hand, no one gives him any feed back on how much they'd pay - I'd take that as clear sign that either the market isn't there for people willing to pay for this or he's targeting the wrong market with his marketing.
I had the same thing in mind as PaulJoslin. This app might just sound like a feature. So I thought putting in a number isn't good unless I know the usage and what others have in mind.
Invoices aren't a uniform bunch. Its general format changes very much based on the industry and location.
The two options would be to either target a niche audience initially and grow from there, or focus on building a general purpose solution that can cater to a dynamic range of requirements. The second option might not be particularly wise in the early stages.
My mother-in-law would love this.
Is there a way, she could get a pre-filled email each time that she could just edit and then send off?
She sends just a few invoices at the end of each month, but each month she has to be reminded what to do.
Your project is much simpler, so hopefully she'll find it easier to remember what to do.
Also, I think there might be a typo on your "Guide" page. Did you mean to have "Customer name and address" and "Invoice items" at the end of the "me" and "customer" addresses, respectively?
Inbound emails are with the help of the lovely guys at PostMark - http://postmarkapp.com. They have webhooks. That'll post inbound emails as JSON to your app.
Other than that, Rails + Postgresql + Nginx + Redis
Wow I hadn't heard of postmark. That would make processing emails from users really easy!
Now I just need to think of a business idea where I process emails from users. Hmm, how about a service where users can forward emails and it automatically creates an appointment on their calendar?
Seems like a novel idea. My suggestion would be to change the design of the website. Make it vertical instead of horizontal --- i.e. input above the output. That way it'll display properly on an iPhone. Clearly you have the technical chops... Now you need to find a good designer to work on your bootstrap theme!
Even as a designer, the process of creating new invoices isn't this easy even when I have a pre-existing template, so this is awesome. Is there a possibility that I could upload my own layouts and make them available for myself others down the road?
I was using bootstrap on the site before. I kept tweaking it and realised I had to do a lot of tweaks to get it to a state I need. So I removed it in favour of custom design.
Thanks for the feedback. I'll style up the pricing page soon.
I just sent you an email about this but did you know that the design of your site is almost identical to what I just recently launched (https://writeapp.me - once you register an account and log in you'll definitely know what I mean). Colors, layout, buttons... errily similar. Honestly, definitely not saying you did it on purpose and even if it was on purpose I don't mind. In fact I'd be flattered! I'm just pretty amazed at how 2 different people came up with something so seriously similar.
Edit: I see you just signed up for an account (I get texts when new users sign up) so you probably never saw my design before which makes this even more awesome. By the way, I'm really diggin' CreateMyInvoice. Awesome work.
Quick tip: You don't have to specify the "me" section from the second invoice onwards unless it's different. Your previously saved name and address will be used :)
> please let us know what amount you would like to pay every month. http://createmyinvoice.com/pricing
Feedback: The pdf looks nice! I worry about parsers not getting things right (and, er, me not getting things right for the parser, typos, mistakes etc.), so this scares me a little. Plus, the "5 invoices" is also "5 attempts", discouraging trial-and-error to get it right. It would be great if you could somehow address the developer problem, of asking for money, by closing the gap even more. It does help already, great if it could help more - that is, focus on what will help someone accomplish their task, not on the actual code or product, what it does, how it does it. Just changing the process or steps might help; or changing the copy on the website (the way it's presented).
e.g. If it formed a buffer between you and the customer (like a secretary), so you just state the straightforward, factual information (no stress!), as if talking to a friendly ally (who is on your side!), and then it takes care of the rest of it - including sending it. But if you went that route, there needs to be a way to check it. Sending incorrect invoices is also scary!
EDIT I don't mean the parser fails to parse in a technical sense, I mean it didn't do what you wanted/expected. It's pretty common (think: regex problems).
EDIT2 I was thinking that a markdown-like syntax might work well, because more familiar - but then I remembered that I often test my markdown to check it does what I think. Same issue.