I've been working on an iOS app that aggregates cinema showtimes across chains and independent theaters in the UK.
I moved to London some years back, and was pleasantly surprised by the vibrant cinema scene, that seems to be in a steep decline in so many places. On any day of the week, one can find independent films, old and new classics, Q&A's with filmmakers etc. playing in one of the many theaters across the city. Staying on top of it all is a chore though, and I found myself missing out on screenings regularly, because I didn't check that one cinema's website on time.
This is also my first time building and releasing an independent app. The journey from research, backend development and learning SwiftUI has been a trip. Released on TestFlight a couple of weeks ago.
Location: London, UK
Remote: Yes
Willing to relocate: No (possibly at a later date)
Technologies: Python, JavaScript, Node.js, Swift, C#, Linux, Docker, Git, AWS, Google Cloud, PostgreSQL, React
Resume: https://www.linkedin.com/in/martin-raag-391a2430/
Email: martin.raag[at]gmail.com
I’m a software engineer with over 10 years of experience. I’m mostly focused on backend development, but have been involved in a variety of projects during my career, including distributed systems, test automation, web apps and data processing pipelines. I have 2 years management experience as the Head of Engineering at a post series-A startup.
Ideally, I’m looking to join a committed team working on interesting challenges full time, but am also open to consulting opportunities.
I use those GDRP screens for a little moment of mindfulness now to consider, whether I really want to read the article behind it. The answer has turned out to be almost always no and I don’t think I’ve missed much.
I'm incredulous about the average person having enough knowledge about the possible pros and cons of these choices. Nor should they - that's what representative democracy is for. A popular referendum for a complex issue like this, is in my opinion, a very bad idea.
Yes! Brexit is the best example for it.
Not judging about It, but clearly non off the politicians that proposed Brexit did a basic research or investigation for such a huge change and about how it should work and what is the impact. Which means they had a different goal.
You should make sure you have the right people in the system to make the right decisions.
Manipulating majority is not hard. And wrong politicians even from outside the system will do it just for the sake of taking power and their own interests.
That's not the case. Many of the politicians who campaigned for Brexit have a very deep understanding and had been campaigning for it for large parts of their adult lives.
Indeed, so far their predictions appear to have been more accurate than those of the so-called "experts". For instance "experts" claimed voting to leave would destroy 500,000 to 800,000 jobs. The Brexit campaigners said it wouldn't. The experts were wrong.
Be very wary of assuming that:
a) The people claiming to be experts on a topic are experts
b) Experts on a particular topic exist at all
c) Experts will make better decisions than the people in aggregate
There are all sorts of reasons to doubt all three of these propositions.
Free Will by Sam Harris had a great affect on how I view the people and by proxy the world around me.
He argues that anyones decisions are a direct result of the physical structure of their respective brain, which in turn is moulded by their genes and experience so far, rather than a by an unexplainable free will.
The book made me reconsider how people treat each other because of their beliefs and actions - from harbouring negative feelings towards somebody due to their opinions to locking up people for committing crimes.
At the very least it has helped me in personal relationships and encouraged me to try to understand where another persons opposing viewpoint is coming from rather than feel negativity or superiority towards them because I feel they are wrong.
I've seen a similar situation play out at a startup and I can see your point. However, I think there's a difference between talking to potential customers about requirements they have vs. promising to deliver a solution for them on the spot.
IMO you don't have to, or rather shouldn't, close the sale when first reaching out to potential customers like this. The goal should be to simply validate the problem statement - if that's done with enough potential customers you should move on to the next part of planning and building the initial implementation.
To your point, new information might still surface at this point, which could lead to the project being dropped. Having not sold (promised a solution) to anyone at this point, the likelihood of unhappy clients is rather low.
All that said, I think calling this initial work "sales" might give the wrong impression here, as I would categorise it more as market research. Whoever is carrying this work out should be very aware of this and not actually close the sale on something they are uncertain can be delivered in a profitable manner.
I totally agree with you if we are talking about preliminary market research, which also usually involves components of research into the technical investment required.
That said, the article of this post seems to emphatically say something different: that you should actively _sell_ before building. Not merely collect research, but to sell stuff you do not already have the capability to deliver, and then somehow backfill that delivery capability after getting customer buy-in.
I’d say even for some new CRUD app, assumptions that it will be easy to build are so, so common, and the reality of most “super simple CRUD apps” is that the implementation is way harder than you thought, and selling advanced features before you definitively know how to build them is a big source of failure for seemingly straightforward products.
It’s very much sales hubris to ever believe you know how to build something you’ve never built before, even in cases when it might seemlike a minor variation of something you built before.
My take is that the purpose is not to actually close a sale before building, but to make sure that you could actually close a sale.
The article makes the correct point that many people confuse "being sort of close to closing a sale" with actually closing a sale, and these people may waste time building a product that clients are only sort of interested in but aren't willing to actually pay for.
I'd also add that you should find common requirements that customers have and build your solution around those.
Much better to have 100s of customers using a product with 1 feature, than 1000s of customers using a product with 1000s of features (with the corresponding overhead).
Inspired by a blog post, which I think made rounds on HN as well, I customised my Touch Bar using a Mac app called BetterTouchTool.
Now I have shortcuts to my most used apps on the left, a Now Playing display connected to Spotify in the middle and audio controls (including a volume slider that you don't have to expand first to use) on the right.
This setup is always displayed, regardless of the app currently on the foreground. This means the controls are once again in a predictable place for my fingers and has made using the touch bar a much more pleasant experience.
I moved to London some years back, and was pleasantly surprised by the vibrant cinema scene, that seems to be in a steep decline in so many places. On any day of the week, one can find independent films, old and new classics, Q&A's with filmmakers etc. playing in one of the many theaters across the city. Staying on top of it all is a chore though, and I found myself missing out on screenings regularly, because I didn't check that one cinema's website on time.
This is also my first time building and releasing an independent app. The journey from research, backend development and learning SwiftUI has been a trip. Released on TestFlight a couple of weeks ago.
https://qino.app