Skaffe med-gründer eller outsource

[sda030]

Vi har et webkonsept som det i følge Google og den europeiske patentdatabasen ikke finnes noe konkurranse på, bortsett fra dagens (dårligere) løsninger. Det blir en ganske avansert løsning i forhold til en nettbutikk eller nettbank, men sikkerhetskravene er minst på nivå med en god norsk nettbank/MiSide. Som alle andre starter vi i det små, men målet er, som med alle andre, å komme opp i 1000 superbrukere og 10 millioner individuelle brukere etter 3 operasjonelle år.

 

Jeg har ca 100 - 200 000kr til rådighet, hvorav minst 40' forsvinner nå til patentsøknaden. Mer må tjenes inn i bijobb underveis. Hele forretningsplanen (30 sider and counting) har tatt form, de tekniske avgjørelsene ved konseptet er tatt (men mer rådføring er nødvendig) og jeg er i gang med å planlegge databasens mange tabeller, osv. Ingen av oss har erfaring/kunnskaper nok til selve gjennomføringen, men jeg sitter daglig med videreutvikling av konseptet og utforsking av hvilke "teknologier" som best passer.

 

Problemet: Vi har ingen bekjente IT-kyndige som jeg vil ha med i prosjektet (vi har høye krav) og vårt nettverk innen IT, entreprenørskap og ventureinvestorer er også lite generelt sett. Altså er vi i en situasjon hvor vi har en potensielt svært god forretningsidé (tallene kan gis senere), men ingen mulighet til å gjennomføre den alene (jf. Mark Zuckerbergs hybel på Harvard). Å gi den bort/glemme den er helt uaktuelt, om jeg skal kunne leve videre uten angst og depresjoner fordi noen andre gjennomførte den.

 

Sånn jeg ser det står vi mellom to-tre hovedvalg:

 

a) Vi bruker en del tid på å rekruttere en dyktig programmerer i HTML, PHP, MySQL, Linux og IT-sikkerhet, matematikk og statistikk. Denne må da betales av egen lomme/lån eller gis store deler av andelene.

+++

• Man får det som man vil ha helt fra starten, dersom partneren faktisk kan alt han/hun sier på intervjuene.
  
• Det er også helt klart billigst i starten når man har lite cash.
  
• Man har allerede et lite team, som viser at flere støtter konseptet. Dette teller positivt i møtet med investorene.
  

---

• Da må vi nok dele en større bit av kaken før vi snakker med investorene.
  
• Jeg har ikke noe imot å dele, men av taktiske årsaker er det ikke så lurt å involvere for mange før investorene har dratt frem sine kontakter. Det er jo ikke sikkert at den som utvikler det i starten er den man vil ha med som partner hele veien. Det er vel heller ikke helt utenkelig at aktive investorer gjerne vil ha med "sine egne" IT-folk.
  
• Dessuten er det alltid en risiko for at utvikleren ser på gründeren som unødvendig og inkompetent (godt mulig i vårt tilfelle), selv om gründeren (meg) har utviklet ideen hele veien. Jeg er litt paranoid for at investorene og utvikleren skal skyve ut gründeren (noe som visstnok har skjedd flere ganger i USA).
  

 

b) Vi kontakter et IT-konsulent firma som utvikler løsningen, samtidig som jeg finner ut hvordan enkelte av de matematiske spesialfunksjonene må utvikles. Jeg jobber som en helt med å lære meg MySQL samt alt det andre en gründer må kunne (økonomi, markedsføring, etc). Så kontakter vi investorene og viser til at jeg allerede har brukt egne penger på prosjektet og at vi allerede har sjekket at konseptet er mulig.

+++

• Mye lettere å finne meget dyktige folk senere når investorene er på tråden.
  
• Færre andeler å måtte dele ut i starten til folk som kanskje ikke kommer til å være med hele veien fordi kompetansen ikke er høy nok.
  
• "Kvalitetskontrollert" av dette profesjonelle firmaet at patentets prinsipper lar seg matematisk programmere.
  

---

• Kan bli dyrt om man ikke gjør ting på egenhånd først.
  
• Kan være at man må endre på store deler av tjenesten senere når en partner kommer inn i bildet og peker på hva som må endres til et sikrere system, eller hva som må byttes til en annen leverandør.
  

 

Sammendrag av spørsmålene:

1. Ideer til hva som høres fornuftig ut?
   
2. Er det mye dyrere å få en prototype (ev. proof of concept) utviklet av et profesjonelt IT-konsulentfirma enn å ansette en med-gründer selv? Hvor mye får man for 100 000? (litt upresist spørsmål, men jeg har ikke funnet noe man kan sammenligne vårt produkt med)
   
3. Er det store ekstrautgifter å konvertere et nettsted utviklet i PHP til f.eks. JBoss, om man senere finner ut at det er mye bedre; så store at det anbefales å få det riktig på første forsøk?
   
4. Hvordan kommer man naturlig i kontakt med potensielle IT-guruer? Hvor lever de og hvor samles de? Trenger man kikkert for å se dem? Neida, men noen tips til hvilken pub eller nettverk man bør innsmigre seg inn i? Det er viktig for oss å vurdere personen lengre enn et par e-poster, da vi ser for oss lengre samarbeid (irrelevant hvilken av de to løsningene ovenfor vi velger).
   
5. Om det er noen her med masse kompetanse og erfaring, som IKKE har tid/lyst til å være med på vår programmeringsoppgave, men som gjerne kan være en rådgivende mentor så er vi veldig åpen for det, under forutsetning av NDA/NCA. Det blir i så fall lunsj/el.l. i Oslo-området, og ev. betalt honorar ved svært nyttig og mye informasjon (dog ikke mer enn taksten hos en IT-konsulent).
   

 

Selv er jeg en oppegående studerende (ferdig med bachelor) på 24 år. Det er jeg som står for konseptet, men har støtte fra andre (som heller ikke har teknisk bakgrunn). Vi er IKKE en av de som tror man kan lage et nytt sosialt medium som skal konkurrere mot Facebook eller de andre 20 konkurrentene... Vi er derimot så dristige å påstå at vi har mulighet til å endre verden samtidig som vi bør få inn et solid overskudd som vil kunne gi både teamet og investorene nok til oregano på maten.

[sda030]

Det må forresten legges til at fortsatt står ett meget vanskelig punkt uløst, 3 problemer hvor det finnes alternative løsninger, og sikkert noen "unknown unknows" som Donald Rumsfeld sa. Det er noe av dette en mentor kunne hjulpet oss med, særlig om du har erfaring med IT-økonomi, sikkerhetsløsninger og/eller matematikk.

[Wattengård]

Man bør ikke basere seg på at man kan "flytte over" til et annet språk/rammeverk i etterkant. Det kan få katastrofale følger.

 

Jeg ville, før det i det heletatt blir utviklet en eneste linje kode, tatt kontakt med en flink it-konsulent/arkitekt (f.eks. Bekk) og gått gjennom prosjektet med de. De har nok ingenting imot å skrive under NDA. Det vil nok koste noen kroner, men det kan være kritisk å få god hjelp til å sette ned en prosjektplan for utviklingen. Når det er gjort kan det være enklere å leie inn utviklere eller evt. ansette noen selv.

 

-C-

[sda030]

Da har jeg tatt kontakt med dem om pris. Får se om de bryr seg om en liten fisk som oss.

[tingo]

Veldig bra forslag fra ChristianW; hvis du ikke får respons hos Bekk (men jeg kan ikke skjønne hvorfor det skulle skje), så bør du finne noen andre som kan bistå.

 

Og en ting til: man får ikke en sikkerhetsløsning på høyde med "en god norsk nettbank" for bare 150'. Folk som tror det undervurderer kraftig hvilke sikkerhetstiltak som inngår i sikkerhetsløsningene til gode norske nettbanker.

[sda030]

Veldig bra forslag fra ChristianW; hvis du ikke får respons hos Bekk (men jeg kan ikke skjønne hvorfor det skulle skje), så bør du finne noen andre som kan bistå.

 

Og en ting til: man får ikke en sikkerhetsløsning på høyde med "en god norsk nettbank" for bare 150'. Folk som tror det undervurderer kraftig hvilke sikkerhetstiltak som inngår i sikkerhetsløsningene til gode norske nettbanker.

 

Ikke fått svar enda, men så ser de vel hovedsakelig etter de store selskapene og institusjonene. Ja, jeg regner med det koster mye (sikkert flere millioner) for gode sikkerhetsløsninger, som jo må testes og finpusses før lansering. Men da er del vel nesten ikke vits i å utvikle noe som helst før man har kapital til å begynne på sluttproduktet?

[tingo]

Ja, jeg regner med det koster mye (sikkert flere millioner) for gode sikkerhetsløsninger, som jo må testes og finpusses før lansering. Men da er del vel nesten ikke vits i å utvikle noe som helst før man har kapital til å begynne på sluttproduktet?

Nei, det er ikke det jeg mener. Enhver idé fortjener en skikkelig vurdering, og dersom man finner ut at den har noe for seg, så bør den realiseres.

 

Men - ta høyde for at det kan komme kostnader til nødvendige justeringer i løsningen (eksempel: sikkerhet, skalerbarhet, tilgjengelighet) på et senere tidspunkt dersom løsningen blir en suksess. Ned riktig planlegging, så har man både kapital, ressurser og tid til å gjøre dette når det er tid for det.

 

Merkelig nok, så tenker "alle" på ny funksjonalitet som skal komme inn i løsningen på forskjellige tidspunkt, men veldig mange glemmer de andre tingene som skal sørge for at løsningen overlever og forblir på topp etter at suksessen er oppnådd.

[sda030]

Merkelig nok, så tenker "alle" på ny funksjonalitet som skal komme inn i løsningen på forskjellige tidspunkt, men veldig mange glemmer de andre tingene som skal sørge for at løsningen overlever og forblir på topp etter at suksessen er oppnådd.

 

Kan du utdype? Tenker du på "vedlikehold" av eksisterende funksjonalitet kontra "fancy" nye funksjoner? Selv om vi åpner for særlig ett spesielt utviklingspotensiale så er det viktigst for at basisen er stålsterkt, mtp sikkerhet og driftsytelse. Det blir intet multimedia og kun stor trafikk til enkelte tider, men problemet blir nok dette med sikkerhet mot phishing og DDoS.

 

Nei, det er ikke det jeg mener. Enhver idé fortjener en skikkelig vurdering, og dersom man finner ut at den har noe for seg, så bør den realiseres.

 

Jeg mente at vi kanskje burde droppe å lage prototypen og heller gå direkte for lanseringsproduktet. Det er jo ikke noe vits i å kaste bort 50-100' på en prototype som må forkastes pga økte sikkerhetskrav allerede før lansering.

[NevroMance]

Tror det som menes er at ting burde planlegges. Med god planlegging trenger ikke en prototype å forkastes, bare bygges videre på. Ting burde bygges opp slik at det er enkelt å legge til ny funksjonalitet og forbedre allerede eksisterende funksjonalitet. Det sparer penger i det lange løp.

[Nator]

Så lenge løsningen ikke er basert på Oracle burde det gå bra.

 

Fra nestenspøk til alvor, er enig med NevroMance it at du kan utvikle hele prototypen slik at sikkerheten ivaretas "godt nok", og med riktig oppbygning og god planlegging kan hele sikkerhets-"modulen" byttes ut eller bygges på ganske enkelt senere.

[tingo]

@NevroMance: spot on! Nator har også skjønt det.

Endret 28. februar 2011 av tingo

[quantum]

Bare noen helt løsrevne kommentarer i ingen spesiell rekkefølge:

 

1) Det er veldig mange dyktige folk som implementerer på lamp-stacken. Men veldig mange ikke fullt så flinke også, det er muligens enklere å finne/identifisere riktig kompetanse om du velger en annen plattform.

 

2) Lære seg mysql høres ikke ut som det du bør prioritere nå, hvis du ikke kan fra før av. Du kan kanskje ha nytte av å kunne nok databasemodellering til å kunne diskutere med de som evt. skal implmentere databasen.

 

3) Med veldig store forbehold om at jeg ikke aner hva som skal lages; men du nevner millioner av brukere og «sikkert som banken» osv... kanhende mysql/php ikke er tingen rett og slett? Med riktig kompetanse vil nok løsningen stå oppreist nesten uansett plattform, men det er et par strategiske valg å ta, er det f.eks. en risiko å bruke Java isteden iom. Oracles oppkjøp? Og i såfall, er det tilsvarende risiko mht. MySQL? Risiko å bruke den lukkete teknologien til Microsoft? Som en annen skriver her; Ha dette på stell fra starten, ikke «sats på» å konvertere til en annen plattform senere.

 

4) Du sier både at de tekniske avgjørelsene er tatt OG at dere driver med utforsking av tenkologier. Ergo er dere ikke helt på track ... overfor investor ol. vil det nok være lurt å fremstå som mer konsistent og si f.eks. at alle teknologiske valg ennå ikke er tatt.

 

5) Du skriver at det ikke er noen vits i å bruke X tusen på prototype som likevel skal kastes. Det vil jeg hevde er ganske selvmotsigende. Prototyper som er ment for å kastes har absolutt sin misjon, enten det er snakk om teknisk funksjon som skal testes, salgsfremstøt eller annet. Dessuten; det er ingen lov som sier at prototyper må kastes, man må bare være dønn klar over hva man driver med hele veien. Dersom man tar avgjørelsen om at prototypen ikke skal kastes LIKEVEL, på slutten av prototyping-løpet, er det mye som kan tyde på at man kan få problemer senere. HUSK at v. prototyping, særlig prototyping hvor prototypen kastes, er det IKKE selve prototypen som er det viktige utkommet av prosessen, men alle erfaringene man gjør, spesielt de dårlige erfaringene man gjør seg for en billig penge er gode å ha med ;-) Husk også at prototyper kan fylle helt ulike behov, det kan f.eks. være fornuftig å lage en mockup-prototyp av sikkerhetsmodulen - selv om den både er velspesifisert og teknologisk definert - bare for å ha noe f.eks. gui-prototyp - laget for helt andre formål - kan samvirke med.

 

Edit: Sa jeg tenkologier? Mente selvsagt teknologier :-P

Endret 27. februar 2011 av quantum

[sda030]

Bare noen helt løsrevne kommentarer i ingen spesiell rekkefølge:

 

1) Det er veldig mange dyktige folk som implementerer på lamp-stacken. Men veldig mange ikke fullt så flinke også, det er muligens enklere å finne/identifisere riktig kompetanse om du velger en annen plattform.

 

2) Lære seg mysql høres ikke ut som det du bør prioritere nå, hvis du ikke kan fra før av. Du kan kanskje ha nytte av å kunne nok databasemodellering til å kunne diskutere med de som evt. skal implmentere databasen.

 

3) Med veldig store forbehold om at jeg ikke aner hva som skal lages; men du nevner millioner av brukere og «sikkert som banken» osv... kanhende mysql/php ikke er tingen rett og slett? Med riktig kompetanse vil nok løsningen stå oppreist nesten uansett plattform, men det er et par strategiske valg å ta, er det f.eks. en risiko å bruke Java isteden iom. Oracles oppkjøp? Og i såfall, er det tilsvarende risiko mht. MySQL? Risiko å bruke den lukkete teknologien til Microsoft? Som en annen skriver her; Ha dette på stell fra starten, ikke «sats på» å konvertere til en annen plattform senere.

 

4) Du sier både at de tekniske avgjørelsene er tatt OG at dere driver med utforsking av tenkologier. Ergo er dere ikke helt på track ... overfor investor ol. vil det nok være lurt å fremstå som mer konsistent og si f.eks. at alle teknologiske valg ennå ikke er tatt.

 

5) Du skriver at det ikke er noen vits i å bruke X tusen på prototype som likevel skal kastes. Det vil jeg hevde er ganske selvmotsigende. Prototyper som er ment for å kastes har absolutt sin misjon, enten det er snakk om teknisk funksjon som skal testes, salgsfremstøt eller annet. Dessuten; det er ingen lov som sier at prototyper må kastes, man må bare være dønn klar over hva man driver med hele veien. Dersom man tar avgjørelsen om at prototypen ikke skal kastes LIKEVEL, på slutten av prototyping-løpet, er det mye som kan tyde på at man kan få problemer senere. HUSK at v. prototyping, særlig prototyping hvor prototypen kastes, er det IKKE selve prototypen som er det viktige utkommet av prosessen, men alle erfaringene man gjør, spesielt de dårlige erfaringene man gjør seg for en billig penge er gode å ha med ;-) Husk også at prototyper kan fylle helt ulike behov, det kan f.eks. være fornuftig å lage en mockup-prototyp av sikkerhetsmodulen - selv om den både er velspesifisert og teknologisk definert - bare for å ha noe f.eks. gui-prototyp - laget for helt andre formål - kan samvirke med.

 

Edit: Sa jeg tenkologier? Mente selvsagt teknologier :-P

 

Takk for rådene. Ang. punkt 1 og 3 så slo det meg også nå at Oracle kan bli usikkert. Jeg leter etter en oversikt/sammenligning over bruksområder, svakheter/styrker til forskjellige amp-løsninger eller bare alle teknologier innenfor temaet. Men jeg finner kun sammenligninger over funksjoner.

 

Når det gjelder punkt 4 så formulerte jeg meg litt dårlig. Jeg mente at "konseptdiagrammet" og alle funksjonene, hvordan de skal løses (prinsippielt), osv. er mer eller mindre klart. Det som ikke er helt klart er hvilke tekniske løsninger (tilbydere) som fungerer best til å bygge konseptet, noe som skyldes at vi ikke kjenner alle "språkene" godt nok. Man vil jo selvsagt ikke gå for middels løsninger når det er store summer man flytter på. Jf. også tipset om å velge riktig fra dag én.

 

Punkt 5): Ja, jeg var kanskje litt fatalistisk, iom at en prototype også er veldig interessant for en investor. Problemet er bare at selv en gui-proto uten mockup-moduler (både sikkerhet og annet) nok også blir dyrt. Heldigvis greier vi fint å overføre visjonen muntlig, men en prototyp er jo viktig for å avdekke svakheter. Kjenner jeg blir veldig motivert av å lese deres råd.

[quantum]

 

Takk for rådene. Ang. punkt 1 og 3 så slo det meg også nå at Oracle kan bli usikkert. Jeg leter etter en oversikt/sammenligning over bruksområder, svakheter/styrker til forskjellige amp-løsninger eller bare alle teknologier innenfor temaet. Men jeg finner kun sammenligninger over funksjoner.

 

Når det gjelder punkt 4 så formulerte jeg meg litt dårlig. Jeg mente at "konseptdiagrammet" og alle funksjonene, hvordan de skal løses (prinsippielt), osv. er mer eller mindre klart. Det som ikke er helt klart er hvilke tekniske løsninger (tilbydere) som fungerer best til å bygge konseptet, noe som skyldes at vi ikke kjenner alle "språkene" godt nok. Man vil jo selvsagt ikke gå for middels løsninger når det er store summer man flytter på. Jf. også tipset om å velge riktig fra dag én.

 

Punkt 5): Ja, jeg var kanskje litt fatalistisk, iom at en prototype også er veldig interessant for en investor. Problemet er bare at selv en gui-proto uten mockup-moduler (både sikkerhet og annet) nok også blir dyrt. Heldigvis greier vi fint å overføre visjonen muntlig, men en prototyp er jo viktig for å avdekke svakheter. Kjenner jeg blir veldig motivert av å lese deres råd.

 

Det er mye «storm» rundt Oracles oppkjøp av Sun nå, og det verserer usikkerhet rundt fremtiden til Java osv. Ville ikke bekymret meg så mye om dét, selv om det er uheldig at Oracle stadig driver å kjøper seg opp på ymse vis. Og Java EE er ikke det eneste alternativet heller.

 

Når det gjelder MySQL så ville jeg bekymret meg mer, i den leiren er det mye rot, og det er ikke bare Oracles skyld. Prøv å orientere deg litt i hengemyra rundt MariaDB, MySQLs forhold til standarder, etterslep av manglende funksjonalitet osv. osv. På den annen side, det ér mye som snurrer oppå MySQL, ingen tvil om det. Ville vurdert Postgresql som et opensource-alternativ, og dersom økonomien var der ville jeg vurdert Oracle db.

 

Når det gjelder amp/lamp så er jeg ikke så veldig begeistra selv, men det skal ikke påvirke deres avgjørelse. Men jeg vil si at du nok har litt for smalt scope om hele teknologistrategien skal baseres på at du vurderer ulike amp-løsninger (hvis det er "amp" som i "lamp" du sikter til da

[sda030]

Det er mye «storm» rundt Oracles oppkjøp av Sun nå, og det verserer usikkerhet rundt fremtiden til Java osv. Ville ikke bekymret meg så mye om dét, selv om det er uheldig at Oracle stadig driver å kjøper seg opp på ymse vis. Og Java EE er ikke det eneste alternativet heller.

 

Når det gjelder MySQL så ville jeg bekymret meg mer, i den leiren er det mye rot, og det er ikke bare Oracles skyld. Prøv å orientere deg litt i hengemyra rundt MariaDB, MySQLs forhold til standarder, etterslep av manglende funksjonalitet osv. osv. På den annen side, det ér mye som snurrer oppå MySQL, ingen tvil om det. Ville vurdert Postgresql som et opensource-alternativ, og dersom økonomien var der ville jeg vurdert Oracle db.

 

Når det gjelder amp/lamp så er jeg ikke så veldig begeistra selv, men det skal ikke påvirke deres avgjørelse. Men jeg vil si at du nok har litt for smalt scope om hele teknologistrategien skal baseres på at du vurderer ulike amp-løsninger (hvis det er "amp" som i "lamp" du sikter til da

 

Ok.

Når det gjelder etterslep av funksjonalitet så virker det som at MySQL skal gå fint siden det ikke er snakk om de altfor kompliserte operasjonene som skal utføres. (Eller sikter du til patcher og den slags?)

Økonomien er nok ikke der for Oracle Db de første 4 årene, så nei.

 

Når du snakker om lamp så regner jeg med det er ulike IKEA-lamper og antall Ohm disse har, som du snakker om?... (men jeg skal ikke skryte på meg at jeg vet så mye)

Med scope, mener du kunnskapsnivå eller ambisjonshorisont? Som skrevet kan jeg/vi ikke selv bygge dette opp fra den tekniske siden, så mitt fokus er på finansen og forventede dilemmaer (sikkerhet vs. fleksibilitet). Og så vil jeg gjerne lære så mye som mulig om de forskjellige alternativene. Teknologistrategien hviler nok ikke på hvilken plattform det skal kjøres på, men det er valg av plattform så er et av de totalt ubesvarte spørsmålene. Og lønnsomhetskalkylen baseres jo på variabelen hvilke løsninger som benyttes (Oracle, Microsoft=$) mens f.eks. sikkerhetsnivået er en konstant.

 

Jeg antar jeg høres like kunnskapsløs ut som en bestefar som tror at skype-samtalen blir brutt om man åpner nettleseren samtidig.

[quantum]

Det er du som skriver om «amp-løsninger», men jeg lurer på om vi er helt på nett her. Amp står ofte for Apache-MySQL-Php, og ofte henger det på en L først for Linux. Så jeg antok det var det du sikta til, men det er det kanskje ikke? Med scope så mente jeg at det ville vært for snevert å bare undersøke ymse varianter av dette som plattform for løsningen deres. Men du har jo alt jboss og sikkert andre ting på radaren, så jeg tipper vi rett og slett snakker forbi hverandre.

 

MySQL er etter min smak litt for rotete, iom. forking til MariaDB og ymse. Men versjonene som Oracle gir ut går sikkert en stabil fremtid i møte. MySQL ble veldig lenge utviklet med nesten utelukkende lesehastighet som prioritet, mens det å følge standarder og utvikle de mer «kjedelige» egenskapene som en rdbms bør ha ble nedprioritert. Nå er vel ikke dette etterslepet så stort lengre, men man bør alltid lese appendikset om non-conformance i mysql-manualen, som forøvrig er både utfyllende og bra skrevet. Oppsidene med MySQL er at det fins brukbar clusteringimplementasjon, og man er mange i samme båt, noe som ofte ihvertfall føles bra. Jeg syns MySQL har litt for mange quirks og kløne-løsninger til at jeg helt kan like den.

 

Hvis du har veldig mange brukere hjelper det ikke så mye om hver enkelt kun skal utføre ganske enkle operasjoner. Det kan hjelpe litt, siden mysql ikke alltid er flink til å optimalisere komplekse spørringer og utnytte indekser, men; fins ikke noe fasitsvar her.

 

Når det gjelder lønnsomhetskalkyle så er dere nok ikke de eneste som foretar slike, snarere tvert imot, og Oracle får jammen solgt noen db-lisenser likevel. Wonder why ... men her er det igjen helt umulig å generalisere og ikke heller gi noen fornuftige svar uten å vite hva den glupe ideen deres går ut på

[sda030]

Det er du som skriver om «amp-løsninger», men jeg lurer på om vi er helt på nett her. Amp står ofte for Apache-MySQL-Php, og ofte henger det på en L først for Linux. Så jeg antok det var det du sikta til, men det er det kanskje ikke? Med scope så mente jeg at det ville vært for snevert å bare undersøke ymse varianter av dette som plattform for løsningen deres. Men du har jo alt jboss og sikkert andre ting på radaren, så jeg tipper vi rett og slett snakker forbi hverandre.

 

MySQL er etter min smak litt for rotete, iom. forking til MariaDB og ymse. Men versjonene som Oracle gir ut går sikkert en stabil fremtid i møte. MySQL ble veldig lenge utviklet med nesten utelukkende lesehastighet som prioritet, mens det å følge standarder og utvikle de mer «kjedelige» egenskapene som en rdbms bør ha ble nedprioritert. Nå er vel ikke dette etterslepet så stort lengre, men man bør alltid lese appendikset om non-conformance i mysql-manualen, som forøvrig er både utfyllende og bra skrevet. Oppsidene med MySQL er at det fins brukbar clusteringimplementasjon, og man er mange i samme båt, noe som ofte ihvertfall føles bra. Jeg syns MySQL har litt for mange quirks og kløne-løsninger til at jeg helt kan like den.

 

Hvis du har veldig mange brukere hjelper det ikke så mye om hver enkelt kun skal utføre ganske enkle operasjoner. Det kan hjelpe litt, siden mysql ikke alltid er flink til å optimalisere komplekse spørringer og utnytte indekser, men; fins ikke noe fasitsvar her.

 

Når det gjelder lønnsomhetskalkyle så er dere nok ikke de eneste som foretar slike, snarere tvert imot, og Oracle får jammen solgt noen db-lisenser likevel. Wonder why ... men her er det igjen helt umulig å generalisere og ikke heller gi noen fornuftige svar uten å vite hva den glupe ideen deres går ut på

Joda, var den samme amp jeg siktet til:) Mente bare at jeg visste akkurat dét, men at jeg ikke skal briefe med at jeg kan alt.

 

Aha, nå forstår jeg hva du sikter til.

 

Om du er interessert i å vite mer så ta kontakt på pm så kan vi diskutere vilkårene.

 

Edit: fjernet dumt spørsmål.

Endret 27. februar 2011 av sda030

[Wattengård]

Hvis du har kun overfladisk kunnskap om teknologien, så bør du se helt bort ifra teknologivalg til å begynne med. Valg av teknologi og plattform kan være en av oppgavene til en tilknyttet konsulent.

 

Det du bør ha klart er hva prosjektet skal gjøre, til en viss grad en domenemodell, budsjett og andre overordnede ting.

 

Begynner jo å lure litt på hva du pønsker på

 

-C-

[sda030]

Hvis du har kun overfladisk kunnskap om teknologien, så bør du se helt bort ifra teknologivalg til å begynne med. Valg av teknologi og plattform kan være en av oppgavene til en tilknyttet konsulent.

 

Det du bør ha klart er hva prosjektet skal gjøre, til en viss grad en domenemodell, budsjett og andre overordnede ting.

 

Begynner jo å lure litt på hva du pønsker på

 

-C-

 

Føler jeg er i en litt vanskelig sirkel, for budsjettet krever en viss forståelse av hvilke teknologier som må brukes/implementeres. F.eks. endres jo budsjettet veldig om man veksler mellom å planlegge for et sikkerhetsteam på 5 stk eller 10 stk. Det samme gjelder jo for hvilke databaseleverandører man velger også (kanskje er innkjøpskostnadene lave, men support og videreutvikling dyrt). Så derfor jeg prøver å skaffe meg et så bredt inntrykk som tiden laver til.

Men det høres helt fornuftig ut at en konsulent/partner kan ta seg av detaljstyringen.

Når det gjelder domenemodell, sikter du da til et konseptdiagram? Jeg forsto ikke alt jeg leste om domenemodeller, men er kjent med ER diagram, og har allerede begynt på et slikt på papir. (Det hjalp meg med å se en brist i sikkerheten).

 

Det ser ikke ut som at jeg får svar fra Bekk (jeg er sikkert ikke stor nok). Noen av de følgende som kan anbefales/frarådes?

Itera Consulting AS

Steria AS

Capgemini

Mesan

 

Iversen Consulting

Kristiansen Consulting Ltd

Systemica AS

 

Jeg antar at stort firma=dyrt...

 

Har forøvrig kommet langt på vei med markedsplanlegging (innhente kundelister, utarbeide spørsmål til kundeoppfølgingen, pitch, osv. Ja, bare å lure Christian

 

Forøvrig irriterende mange idioter på forskjellige gründer-forum som snakker om at de har en eller annen "kjempeidé". De skal utvikle en prissammenligningsside for datautstyr! Jeeez... [skal ikke påstå at min idé er innovativ på alle fronter (det var jo heller ikke Fb, Skype, etc. men jeg går i hvert fall ikke for å konkurrere mot noe veletablert.]

[tigerdyr]

Jeg antar at stort firma=dyrt...

 

Dyrt og dyrt... Du må regne med timepriser på 1000-1300 kr/timen (+ mva) avhengig av kompetanse. Til sammenlignen kan du sikkert få 4 indere fra Cap/Tata, men så får du jo gjerne det du betaler for...