Wow. I'm founder of Manager.io and long-time member of HN but I was always afraid to submit on HN link to my own startup thinking it won't ever get any upvotes. There are hundreds of people on www.manager.io right now. I'm amazed and completely humbled by the interest right now.
It's been a while since I didn't comment on anything on HN, but since you are doing something that is really hard and I have some experience with accounting and banking, may I offer you some tips that you might want to investigate further:
- Regulation: Some countries (and some US States) do have guidelines on how this type of software must be constructed, make sure you are compliant to those regulations if it's the case. Example: IIRC you need permits to even start building a POS solutions in some states.
- Integration: An usable accounting software must include HR or have integration with common HR software used by most companies. HR is one of the most complex parts of accounting. Most clients will have outdated solutions they are comfortable working with and won't change completely to your software, make sure you can integrate with tools they want to continue using. Only fight the old if the option you are offering means task elimination. Don't forget you need to integrate with banks, but that's easy.
- Customization: Human systems are not pretty. There are things that do not make sense to accounting and are often loaded with emotional decisions, human relationships and corporate strategy. Sometimes a software just streamlines the human mess, make sure your software can be customized by your clients to a certain point.
lubos, it looks very interesting, but (there's always a but)....
I use QuickenPro (or whatever they call it today) and while I dislike it, it has Maximum Accountant InterOperability (MAIO) - since it's what my accountant's office tends to use.
I really like the idea of a simple, straightforward, just enter the data and get stuff done without getting in my way sort of package, but without AIO and preferably MAIO, I ain't even thinkin' 'bout thinkin' 'bout switchin'.
I suspect I'm not the only one in this boat, and "I dislike that other thing" doesn't really make "the other thing" broken - and if it ain't broke, why fix it? (In other words, the pain of sacrificing MAIO likely exceeds any pain from using "the other thing".)
What plans, if any, do you have for data import/export to ease pain and ensure MAIO?
1.) Manager has already full support for UK VAT. Just enable VAT plugin for United Kingdom. You will get necessary tax codes and VAT return to prepare your VAT.
2.) There is no need to setup financial periods, just setup individual reports for periods you need.
3.) OSX package is bigger because it bundles Mono dependency.
Thanks for the quick reply, I've got the VAT plug in set up, but I can't see how to use the flat rate scheme.
In the flat rate VAT scheme I pay 14% of my turnover, instead of [VAT on invoices] - [VAT on purchases], this saves me a bit of money, but there's not much software that supports it.
Manager has already full support for UK VAT. Just enable VAT plugin for United Kingdom. You will get necessary tax codes and VAT return t(Io prepare your VAT.
Any chance you'd develop a generic VAT plugin? The requirements across Europe must be quite similar apart from rates, periods and invoice/receipts based calculation. I ask, because I doubt there'll be much impetus for you to develop an Irish VAT plugin, given the size of our population and there's no point in even trialling the software without it.
As an outside observer, it seems that providing the desktop app allows the developer to have a freemium model without incurring additional hosting costs for those users. Users who want cloud storage offset his costs directly with the $5 charge.
Just guessing
Side Note, for those who haven't downloaded the app. There doesn't seem to be a mention for the cloud storage option on the home page. The app stores data locally, but offers the option of cloud storage with additional benefits for $5/month. Screenshot: http://i.imgur.com/zWYpv7I.png
Not being a webapp is a huge plus for me if I'm going to use a piece of software for something important (when the use isn't inherently tied to the web).
The people who make this could sell to GoogleAppleSoft, get hit by a bus, or start charging stupid money for it, and I'll still have a copy and all my data. A webapp by a company I've never heard of before needs to do much more to reassure me that won't happen.
If you were to use this, would you really want to give all your detailed financial information to someone else? Who else do you give that info to? So desktop definitely good idea.
How do you deal with conflicts in sync? We have an Accounting software and I liked your offline freemium approach. What are you using for local server? and for database?SQLLite?
Look, I hate Quickbooks and Quickbooks Online. I really, really do, but I will not use a financial product that doesn't connect to my financial institutions. Period.
Do you want to know what MY startup dream is? I want someone to give me money, and then I want to go create a service that kicks the crap out of Yodlee and Intuit's own bank connection system. I want it to use REST APIs when it can, OFX when it should, and intelligent screen scraping when it must.
I want to build a startup based on an open core of specifications for how to connect to every financial system in the world. I want that spec to be executable and available as a simple library with bindings to every language you can think of. If you have a new institution or your bank changes and you can fix it, I want you to be able to fork the library and send us a pull request.
I want end users to be able to go through a "guided login process". "OK, log in now", "OK, click on the accounts list", "OK click on a transaction". "You're done! We've autogenerated a basic scraper for your bank. Thanks for helping us out."
I want to make money off this library by providing a simple, unified REST API behind all this mess that provides the computational resources to handle millions of customers connecting with thousands of institutions.
I want this company to provide push notifications so your app can do clever things when people spend money.
I don't want you to have to sign an NDA and pay thousands of dollars just to get permission to play with it.
I want it to be the Twilio of Banks.
But if you want to take the code and go your own way, you can.
I really don't know why we've let just a few companies keep our collective financial data locked up for so long. Is it because it's so expensive to get it working? Well why not spend it on people who will create an open, scalable system that can still make money?
Instead, we have Mint.com and mvelopes. That's it, really. Have an idea for a personal finance tool that lets you create "virtual subaccounts" for your checking and savings accounts so you can leverage double-entry bookkeeping in your personal finances through a clear metaphor? Great! Now have fun spending 10 minutes every two days copying and pasting stuff from 10 websites into 1.
It's just madness.
You know that "one weird thing" you're passionate about that's not really related to anything else you're passionate about? This is it for me.
P.S.: lubos - this isn't really about you or manager.io. I commend you for making something and getting it out there. This is about the thing that makes every one of these attempts inevitably fail, and it's sad that we're all being held hostage to crappy software because of it. I wish you success, I hope that I'm completely wrong.
That is a really cool service. I can't help but notice, though, that the example on your front page sends bank credentials over http instead of https. Is that particularly wise?
A friend and I are about to launch a personal finance app, and I would absolutely love to integrate this. Right now we just support banks that support Direct Connect. Any chance I can get in? ;)
Argh. When I hear the word 'bank' I automatically put my head in my hands. I had yodlee wired up to import into xero but there was a manual auth step in between. It was so slow that while distrated, waiting for it to run, I burnt my toast and set off the fire alarm in my building. I have a python script for converting Barclay's PDF statements to csvs and js for ripping my data from HSBC. This is not the wonderful new world I was promised.
It's not a wonderful world scraping that stuff either. I worked on a startup doing just that - we wrote our own after evaluating the various options including yodlee.
The banks make it hard. The only good thing is they evolve like molasses, meaning the crawlers don't break often. But the fragility of it all is crazy. There's a reason yodlee charges so much.
Would almost love to see them open source it all. It's such a pain that open source seems like the ideal solution to scaling development of each crawler.
You make some excellent points, especially the one about banks and molasses. Scraping websites in general is subject to so much arbitrary change you tend to give up after a while.
With reference to the rant about importing data directly into one's accounting software of choice, the random nature of bank data formats is more likely to render it impossible, especially for the application developers who I'd say would be weighed down with maintaining the core application.
I think the best option would be for the core accounting application to have a well defined format for import/export, leaving the work of getting data into that format for another application or project like the ones mentioned in other sub-threads here (simplefin.org looks interesting aready).
I currently use a FOSS (I think) Windows application called TurboCash (turbocash.net) which does a pretty good job, but also requires some working to get bank data in. I'm thinking of trying out ledger-cli, with some hack work on getting bank data in. With my recent drive toward the command line, I'm hoping this may be my accounting Valhalla.
I solved my companies accounting needs with a bunch of Ruby scripts that scrape / download / convert from the banks and then output to ledger-cli. The cool thing is that ledger lets you script everything so you can write another Ruby script that outputs a CSV file that I can upload to the tax authorities. The end-of-quarter tax preparation went from a few days to a few hours.
It works great for us but something breaks about once or twice a year when one of the 3 banks we interface with changes something, so I can see this being very hard to solve generically in a way that works all of the time for non-programmers.
Still, I would recommend this solution to anyone who is comfortable with Ruby and ALSO comfortable with accounting because ledger is great but it also allows you to shoot yourself in the foot if you don't know what you're doing.
I've written what you are talking about for my own personal budgeting (http://www.allocateapp.com). I've never taken it into full production for the same reasons that you are mentioning. It currently supports my banks and anything OFX and works great. But something like Yodlee is what is missing to make it production worthy. It is too expensive for what I want to charge. I'd like to talk to you more. Send me an email - jason@jasonfunk.net
Wow. So privileged are you to live in a country where you have a choice of banks that provide API access.
FWIW, I'd prefer to have automated transaction importing but since I don't, this service actually appeals to me more than the services which tout it has a primary feature.
Man, tell me about it. I worked for a company that wanted bank importing, but couldn't afford yodlee's cost structure (since this company was freemium). As such, they built it themselves, and I worked on it for quite a while. It's hard, but totally doable. I really hope they license that technology as an api someday, because a lot of great finance tools could be built on top of it.
It doesn't require the user to give out their bank account credentials (which OFX does). It's JSON, not XML. There's only one version. The spec is digestable. And access is read-only, to name a few.
Or how about we all start open-source project where we can all contribute scrapping code for each bank and put Yodlee and put this ridiculous bank feeds business out of business? Is anyone seriously interested?
I am. I have experience with most of the technologies we would need (including native code and building browser extensions if we want to build an "auto scraper").
When you do set up the project. please be sure to announce it here. If it is soon enough, an announcement on this sub-thread will also be good for me. I'll keep checking back. :)
Well, it's not there, it's a known problem, and you have passion for it. So I'd encourage you to work up a business case and figure out how to make banking tech "just work". :-)
I really hope also if each bank in the world can provide API for easy bank reconciliation and can auto match with any number provider such as bank in slip number or what ever number.
That's what I use. A simple CSV download of transactions (what bank doesn't offer that?), an awk script or two, and my bank transactions are ledger entries.
Interesting. My immediate question was "is this US-specific", but it seems not: http://www.manager.io/about, section "First-class support for every country".
That was exactly my first thought. Something else encouraging as far as internationalisation is concerned is that the company is based in Australia not the US so they are less likely to be blinkered to only their home market.
Looks interesting. My main concern with something like this is that my accountant won't be able to work with the file it generates, or will charge me more to do so. My accountant, like most others, speaks Quickbooks.
But I'm curious about a few architectural decisions. What made you to decide to build each HTML page by hand?
Code like this[1] makes my eyes bleed... reminds me of the faux-OOP HTML builder classes that used to be a fad among PHP programmers (or ISAPI & Delphi web developers of old) a while ago.. No offence, but much of your Manager.HttpHandlers.* codebase feels like messy, ugly PHP4 code ported to C#...
What made you decide against template-based output rendering (Razor, NVelocity, NHaml, .liquid to name a few)? With template-generated output, the business logic layer could be decoupled from the UI. I had only a cursory glance at your code (and thus could be wrong), but it seems manager.io's DAL/BLL layer is intermingled within the GUI parts.
The protobuf DLL was named protobufnet.dll in the MSI. But the proper filename should be protobuf-net.dll
I think user input validation and error handling could be made more robust.
Additionally, spawning 5 HTTP worker threads to serve a single user seems a little overkill.
These are few of the issues I've noticed during the 5 minute tinkering with your assemblies. But don't let this critique discourage you. The app looks good - I guess end users won't care how it's built so long as it provides real value...
PS: Thanks for the heads up about Eto forms! I'll give it a spin and see how it fares against Xamarin's XWT.
I've been attempting to 'love' Wave for the past couple of days now and it doesn't seem to be happening. I've done the homework on double-entry bookkeeping and have tried to fit my brain into Wave's workflow. Unfortunately, the total lack of documentation on how to get started with it is making life very difficult.
I've downloaded OP's application and whilst it seems much more straight-forward, I've come across a problem with transfers between accounts that makes me feel that it isn't quite ready yet.
Looks like I might have to settle for GNUCash.
I can't believe how difficult it's been to find a solution for simple double-entry accounting that's also self-contained (ie, I can create invoices and attach receipts). Our side project doesn't make enough money to justify spending on Quickbooks or a monthly site subscription, but I'm not convinced that they would be the right answer, anyway.
Sadly I got an exception right after trying to add a company:
System.FormatException: Guid should contain 32 digits with 4 dashes (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).
at System.Guid.GuidResult.SetFailure(ParseFailureKind failure, String failureMessageID, Object failureMessageFormatArgument, String failureArgumentName, Exception innerException)
at System.Guid.TryParseGuidWithNoStyle(String guidString, GuidResult& result)
at System.Guid.TryParseGuid(String g, GuidStyles flags, GuidResult& result)
at System.Guid..ctor(String g)
at Manager.Objects.Get(String entityId)
at Manager.HttpHandlers.File.Upgrade.Get()
at HttpFramework.HttpModule.ProcessRequest(HttpRequest request)
at Manager.HttpModule.ProcessRequest(HttpRequest request)
It appears to be a wrapper around a webservice that runs in process. So I assume the webservice is something like .NET and so they stuck with C# for the GUI bits.
I have a tech related question. It seems like you are running a web server locally and using a web browser component to display the pages processed locally.
Would you care to explain how everything is setup?
Regarding web-server, I'm just using HttpListener class in .NET Framework (or Mono) which is ultra lightweight solution. As per web-browser, Manager doesn't bundle it. I'm just using whatever is available on target operating system, that is Internet Explorer on Windows, Firefox on Linux and Safari on Mac OSX. Lots of credit goes to https://github.com/picoe/Eto which allows easy creation of these cross-platform apps.
When I try to email an invoice, I get an "Error", which isn't very helpful. I can't find anywhere to setup the emailing functionality, so I assume that that part isn't ready yet?
Very nice! Does this pull in transactions from your bank accounts automatically? I'm using Xero right now (awesome BTW) and that is a killer feature for me.
Any interest in making personal accounting software as well? On the Mac, there are few good low-cost options if you want desktop software and not cloud-based.
I'm actually planning to build a native OSX app. Would love to talk more about your needs/pains. Shoot me an email if you get a chance. My email is in my profile.
Seems like you could put the *.manager file into dropbox or another "sync service" and put a symlink into the Users/... folder to point it to the dropbox file, which would probably allow multiple users to all access the same data. I feel like this would sort of be bypassing your cloud service
I don't mind but the problem is, if two people edit the file concurrently, Dropbox won't merge them. It will just create a copy. Cloud Storage is designed to merge changes no matter how many people work on file concurrently.
I hadn't tested and suspected something like that may happen. Just keep in mind it's possible people could hack together their own working versions of a multi-user sync.
No need to hack anything. I'm going to release server edition which will give users multi-user access without putting data into cloud storage. That will settle this matter.
If this works, it could be a new model for software. There's something about accounting that seems more appropriate as desktop software. I like avoiding the monthly fees and it's probably more comforting to the developer not to be serving the app (I realize they are offering cloud storage).
This is really superb. It's quick and responsive. Looks good. Looks easy to use. Will give a test drive over next few days as have to get my taxes done. I see that many of the plugins are disabled so suspect that's the business model.
It would be nice to be able to customize the text in the invoices (for example to translate them to other languages) and be able to add your logo. Also full screen on mac would be very welcome.
Good work. The install process was very smooth. I like that it doesn't require admin. Also a neat architecture. Looks like it's a .NET app running an in process web server.
You should work on integrating this into various niche apps, like WHMCS (webhosting control panel), VOIP panels, basically any reseller panel you can find. It'd take off.
I'd also suggest you create a bitbucket account for issue submission since:
1. You can enable access only to issue tickets
2. you can keep your source code private
3. it's got a low barrier to entry (you don't actually need to keep source code there, but git is awesome and so is bitbucket)
Definitely the export list is a barrier to adoption. Really, it's all I care about.
I'm sure that any small business package is going to have a chart of accounts, invoice creation, etc. What I have to make sure of is that my accountant can import the package's exports and do my taxes. :)
