Our Startup can help other Startups build an MVP
We're a startup that can help you get to your MVP faster by handling your back end for you. We streamline new feature development via a new type of REST API. We're trying to improve and expand our technology, but need real world use cases to do this. By working with your startup directly, we'll be able to do that while providing personal customization and functionality that you need to grow your business. We want to hear your feedback and how we can build features even faster.
Just on a personal note, I was a senior consultant at Red Hat building enterprise solutions before this. I know what it takes and we made our platform to help other startups that are in the same boat as us. Contact us if you're interested: managers@flowstacks.com
Here’s our startup to check us out: https://flowstacks.com/
7 comments
[ 2.7 ms ] story [ 21.4 ms ] threadI'd use it, but perhaps I should first help you fix a couple of things.
1) Go into beta. You need testers first. Give them the stuff for free.
2) Don't link me to documentation to learn more. Create simple, easy-to-ingest screencasts/videos/pictures that I can quickly understand how the software can help me.
3) Build stuff with it. Time is a major sell point for developers who are tired of spending 40 minutes getting some package to work before actually writing code. Show me how I can build Twitter in 30 minutes and you have a winner.
4) Don't only focus on startups. A lot of other companies like APIs these days. Showcase the versatility of your product to big corps/medium-sized enterprise/NPOs/etc on how they can easily get their APIs to be accessed on multiple platforms.
5) Make it easy to get my data in and out. Nobody likes a lock-in these days, so make things more "open".
6) Understand that this is a crowded marketplace. There's a ton of variants around, with Parse/FireBase/etc all competing in a market that feels a bit crowded to me.
7) Target frontend hipsters/lovers of all thing JS. I may sound coy saying it here on HN, but deep down, that is how they are identified as a niche, so target them.
Hope that helps.
1) The Developer Dashboard (https://flowstacks.com/developer/) is for testing new code, managing all endpoints, deployments, database schema (coming this week), and account details from a browser.
2) The command line interface (https://github.com/FlowStacks/cli/blob/master/fs.py) for full API capabilities, scripting, and the latest error handling. We are a command line shop, so we use this to find bugs, and it already reports things like bad JSON syntax, API Validation, Python syntax, Exceptions, and as many other silly errors that really annoyed us.
We’re still building the advanced deployment and database management into the website, but all of the tools are already working from the command line. We are also close to releasing a working Django webserver that uses any Endpoint-level API file (https://github.com/FlowStacks/hello-world/blob/master/api/wo...) for quickly mapping Javascript strings through Django into a working Job[1] hosted on any FlowStacks REST API. This factory style approach to building Jobs extends beyond Django, but since we’re a Python shop we went with it first. We planned on knocking out Rails next, but we are flexible.
Why FlowStacks? As developers, we wanted to have a Job hosted on a REST API where the API Inputs/Outputs can be Job-specific, and we did not care where the Job executed. For us, this API standardization has made us able to quickly build our own dashboard using and testing FlowStacks Jobs like any developer. We want the Dashboard arming developers just like .Net for debugging where streamlined testing drives features out faster, and it has to be simple to use (no Jenkins/Travis it’s all JSON black box testing similar to Postman). We built the command line interface for handling build regressions and showing how to use the FlowStacks User API and REST APIs from the command line. We also built the cli and dashboard for deploying your own GitHub repository into a REST API where your Job code defines the hosted API(dashboard build is coming this week). Jobs are easy to write. There’s only three parts to a Job: inputs[2], outputs[3], and tasks to perform (states)[4]. This allowed us to build some of the first Jobs like our Twitter Poster Job[5] because we did not want to login to Twitter. We also include Redis integration for any Jobs[6] out of the box already, and we use redis extensively for caching and publisher/subscribe patterns.
Our data policy is very open based off feedback we hear. Right now, we use Python’s ORM SQLAlchemy for any schema integration into your REST API’s database instance (https://github.com/FlowStacks/hello-world/blob/master/schema...) and Jobs can also use your new/legacy database(s) outside of FlowStacks. We just need a network connection. Here’s our example included in the Hello World for setting up a REST API Job to establish a connection to any database outside of FlowStacks: https://github.com/FlowStacks/hello-world/blob/master/src/ra...
Post Beta we plan on launching the on premise offering for Enterprise solution...
8) Make your signup simple, only ask for email address & password. Why would you need a username & email address? Both are unique identifiers for a login.
9) Change your website design. a) Go to https://wrapbootstrap.com/ and look for a product theme perhaps like - http://wrapbootstrap.com/preview/WB02N6L1H
b) Take out the slider and instead either alternate features like - http://www.lostmy.name/ or create separate pages for the content. Separate pages can help out better for SEO.
c) The copy for why I should use your software answers what it is? You haven't attacked any pain points or said how much easier you would make it. You have only mentioned that it would be easier and scale but this isn't a proper answer. The best way to do this is to create a narrative or story around the product.
d) Bear in mind that h1...h6 tags are used for SEO which you don't seem to have. Check out - http://www.hobo-web.co.uk/headers/ And only use one h1 tag per page as per Google's recommendations.
e) managers@flowstacks.com seems like it might come across as pretentious if you're marketing to developers and startups although it might work well for enterprise customers. Perhaps you should go for hello@flowstacks.com for general queries and you already have support@flowstocks.com for support.
f) Flesh out your about page a bit more, I want to know who you are and why you are doing this, history and motivations. You could add testimonials to either this page or the homepage. Testimonials at this early point could come from your beta users.
g) Your navigation at the top is broken on your blog page. A home button is added and the sign in / sign up buttons disappear.
h) Minor but the community button on the documentation page goes back to the homepage. Broken?
Jay
I was reading your post on https://news.ycombinator.com/item?id=7321013 and that sounds like it's spot on what we are looking to do right now.
Are you looking to build something still? If so here's my email: jay@flowstacks.com let's get started!
I will sign up in the next few days to give the platform a test.
I won't mind sharing feedback to help you guys grow, but remember that my actual use of the platform should not be a sole feedback tool, as you'll need consensus among a vast amount of testers to gauge the use of the software.
Also, remember not to listen to the users every need. Some are too specific to implement and will bring no value to the product itself.