I've developed this: www.ird.me/tour.html.
But I'm the single developer and the project is getting too big and complex. What options to sell/quit/change you are aware of? Do you have an experiences of overweight projects that you can share?
@ O.P: I read your entire post (thanks for relaying your lessons), and most of it is about internal development and personal "aha" moments.
What about customer driven development , i.e. user testing?
You have no sign up form ...
This boggles my mind - get users already!
This is a classic case of what I personally refer to as un-scientific thought processes. If I ask my my friend "what do you think of this business idea?" Really, what on God's green earth does it matter what he thinks? If he says "its great", does that empirically mean anything? If he says "i hate it", does that empirically mean anything? Who can empirically say anything is anything? In other words: test it. A joke I have with all of my friends; anytime they ask my advice about anything, they already know the answer... test it. You have not tested your product.
Thanks for the notice. Our problem is that I've tried to build lot's of features at the same time. The app became too big, it eats a lot of my time and it's still far from being completed - it's still not ready to be released.
Release early, release often. Once you have some users, they will be the best to guide you to what is working, whats not working and what needs adding. If you specify its beta then they can hardly complaing (espically if you offer some beta testers a discounted rate after release, positive motivation on both sides wont hurt)
DabbleDB is one of those products that I will probably never get to use despite being potentially very useful. Why? Because my company won't let me store proprietary information on somebody else's servers.
If you continue with this project, I would encourage you to consider letting people license the software to run on their company intranets. I know a lot of companies don't want to bother with installation support and such, but to me this seems like a pretty obvious market -- there are countless CRUD apps I could really use at work but just haven't had the time to build from scratch, and if DabbleDB had a not-outrageously-priced intranet solution, I'd buy it in a heartbeat.
You want out. That's really understandable. This was a really ambitious project that quite a few companies have failed at... Last year I worked on a startup by for about 6 months and just got fatigued and scrapped it. I know the pain of working on a project when the momentum starts to evaporate. But what really stands out to me from your extended post is that it seems like you've learned a LOT from this whole experience. Succcccesssss!!! :) Best of luck.
After reading the long version of your question I want to say that my own experience with generic application generators is very similar to yours. Users want functionality and wording that is very specific to particular tasks.
Therefore any generic framework can only ever serve as a basis for you to create specific applications. The question remains whether a generic framework or generator actually makes that task any easier. I doubt it. I tend to end up building one generic framework per application :-)
So what could you do? One thing you should include in your thinking is that CRUD/OLTP + simple reporting is not the only thing people do, and it's probably the most crowded market.
The other thing people do is analyse data. In order to analyse data they have to integrate and clean it first. It's a horribly messy affair, but what it involves is a generic database and user friendly transformation rules.
I know I'm not being very specific, but I think it could useful for you to think a little more about decision support, analytics and data integration. It's what I do as well, so I'm biased.
Your application is big; here's the point. What happened to you is exactly what happened to me 3 year ago when I made a barcode application.
I carried on growing the application until it become so big that I can't control. The read problem is that you "don't know how to solve overweight issues".
I got a solution, but I'm not sure if you'll go for it.
Decompose your website into parts, I don't know how it can be. But for me it was a windows application built with the Dot net frame work. I decomposed it into several namespaces and classes and placed those classes in "DLL" files.
Now the program is much more tinier. I don't care about the DLL files, I just call them to get something ready. Like calling a class, giving information about a barcode and getting back a picture. In reality it's more than 400 line of code to do that. but with OOP and DLL, in few lines I can do it.
Now you have to explore the possibilities of your programming platform.
The screenshots look good, but the terse homepage had me slightly confused about what the product actually does. (Admittedly I'm probably not part of the target market either.)
The one-line description of the product -- "Online web database" -- seems to contain a tautology: if it's on the web, doesn't that imply it's online? Besides, I'm looking at a web browser, so I'm primed to expect a web application.
What's left is just the word "database". Is your product very similar to an established database application, say, FileMaker? If not, then you need to come up with a better description.
My suggestion is to chop it up and develop it piece by piece.
Looking at your app, it seems to do a lot of different things such as:
- Form Editor
- Calendar
- Permission based file access system
You could build just one of these components and get it out of the door and see how the market responds to your product and then evolve the product from that point onwards. Chances are that what you will end up with will look nothing like what what you have in mind.
By the way, you should spell check the home page. easilly = easily